[HN Gopher] Crystal's Interpreter (2021)
___________________________________________________________________
Crystal's Interpreter (2021)
Author : philonoist
Score : 60 points
Date : 2022-06-25 05:00 UTC (1 days ago)
(HTM) web link (crystal-lang.org)
(TXT) w3m dump (crystal-lang.org)
| rvieira wrote:
| I couldn't easily find any info about the interpreter being
| available from the binary releases? Since this is from 2021, is
| it already available?
| hbien wrote:
| It's not in the official binary releases yet. You'll have to
| compile your own Crystal via `make interpreter=1` to use it.
| Instructions here: https://crystal-
| lang.org/install/from_sources/
| compumike wrote:
| Sadly no, the interpreter seems to not be available yet in the
| official binaries. You may use "crystal eval" for one-off
| commands (and can use this to, for example, require a local .cr
| file and call a particular method), but that's certainly not
| the same as an interpreter. :P docker run
| --rm -it crystallang/crystal:1.4.1-alpine / #
| crystal i Crystal was compiled without interpreter
| support / # crystal eval '3.times { |i| puts
| "Hello #{i}" }' Hello 0 Hello 1 Hello 2
| / # crystal eval 'require "http/client"; puts HTTP::Client.get(
| "https://news.ycombinator.com/").body.split("\n").first'
| <html lang="en" op="news"><head><meta name="referrer"
| content="origin"><meta name="viewport" content="width=device-
| width, initial-scale=1.0"><link rel="stylesheet"
| type="text/css" href="news.css?E6T8vRgACsBJvJjCXAU8">
|
| I tried the non-alpine package as well. No dice.
| snicker7 wrote:
| It is good to see languages like Crystal and Julia having both a
| compiler and an interpreter.
|
| I would really like to see a hybrid approach, where an
| interpreter is used for the outer loop and a compiler for the
| inner loop. I believe Guile takes this approach by automatically
| compiling frequently called functions.
| iostream24 wrote:
| Important to note that this is a modality, not the primary way
| to execute crystal code in production, which remains building a
| binary executable. This saves compilation time while developing
| at the expense of performance.
|
| The runtime performance of crystal executables are great, of
| course, comparable with C or C++ in the given web development
| domain, of course, where the Boehm GC isn't a problem, given
| the request response cycle and the standard lib http and socket
| objects, etc
| Zababa wrote:
| > The runtime performance of crystal executables are great,
| of course, comparable with C or C++ in the given web
| development domain
|
| I don't think that's true. Crystal seems to be more in the
| ballpark of Go or
| Java:https://www.techempower.com/benchmarks/
| vanviegen wrote:
| Isn't that the same ballpark?
| chrisseaton wrote:
| > where an interpreter is used for the outer loop and a
| compiler for the inner loop
|
| That's just a standard JIT isn't it?
|
| Also - note there are multiple ways to automatically make a
| compiler from an interpreter, so really you just need the
| interpreter.
| rgrmrts wrote:
| What's a good starting point for someone to study that?
| Specifically going from an interpreter to a compiler
| automatically. Are there any special considerations before
| implementing the interpreter? I'm vaguely familiar with
| RPython which I think delivers on that.
|
| For context: I'm just a hobbyist interested in PLs and want
| to learn more about JITs, I found Crafting Interpreters super
| helpful for a lot of foundational knowledge.
| comment500 wrote:
| ChakraCore, the former JavaScript engine of Microsoft's
| Edge browser, now an open source project, has in its repo a
| decent high-level description of how its JIT compilation is
| integrated: https://github.com/chakra-
| core/ChakraCore/wiki/Architecture-...
|
| I found the source code to be quite readable too, last time
| I delved into it. Also its command line tool ("ch"), when
| compiled in debug mode, has loads of options available to
| show what it's doing internally when it executes a
| JavaScript program.
| chrisseaton wrote:
| Yeah RPython and Truffle/Graal are the two major
| implementations of this idea today.
|
| https://www3.hhu.de/stups/downloads/pdf/BoCuFiRi09_246.pdf
|
| https://chrisseaton.com/truffleruby/pldi17-truffle/pldi17-t
| r...
| Calavar wrote:
| You mean a JIT? Or are you talking about something else, like
| some sort of hybrid interpreter/AOT compilation?
| convolvatron wrote:
| old lisp implementations allowed you to freely intermix
| compiled and interpreted code. it wasn't compiled on demand,
| each function could independently be compiled AOT. and
| dynamically replaced with an interpreted or compiled version
| pjmlp wrote:
| Why the past tense? That capability is very much still
| present in modern implementations.
| convolvatron wrote:
| sorry - its me thats past tense. didn't want to presume
| that things are still done that way. fwiw i don't why
| more environments don't have the same flexibility.
| renewedrebecca wrote:
| This is pretty great, and provides the biggest thing I miss in
| Crystal's functionality compared to Ruby. (that is, a IRB-like
| REPL).
| masukomi wrote:
| it's had an IRB-like REPL for years. It just wasn't built into
| the language. Admittedly it was limited compared to IRB but it
| was more than enough to test out quick ideas.
|
| It's called ICR: Interactive Crystal
|
| https://github.com/crystal-community/icr
|
| the first release was back in 2017
___________________________________________________________________
(page generated 2022-06-26 23:00 UTC)