[HN Gopher] Building a Lox Interpreter in Julia
___________________________________________________________________
Building a Lox Interpreter in Julia
Author : lukemerrick
Score : 43 points
Date : 2023-06-02 04:40 UTC (1 days ago)
(HTM) web link (lukemerrick.com)
(TXT) w3m dump (lukemerrick.com)
| lukemerrick wrote:
| Disclaimer: I wrote this blog post. If this were an "Ask HN"
| post, though, the question would be "What next after reading
| Crafting Interpreters?" I have only done the tree-walk
| interpreter half of the book, but I'm already excited to move
| beyond Lox, and I'm curious to hear what others have done in this
| situation.
| borodi wrote:
| You can try and build your own toy language for fun, or try to
| compile lox to some assembly/llvm ir.
|
| Another option is to try and contribute to an existing language
| (Julia ;) ).
| TwentyPosts wrote:
| Personally, I found "Writing an Interpreter in Go" better than
| "Crafting Interpreters". It has a follow-up book titled
| "Writing a Compiler in Go", which (similar to Crafting
| Interpreter's second half) implements a virtual machine. The
| books take a lot of inspiration from Crafting Interpreters.
|
| If this sounds at all appealing to you, I would check it out. I
| found Monkey so far somewhat more compelling than Lox (might be
| personal preference, though), and I thought the exposition (and
| code quality) was overall better. Go is also very easy to pick
| up.
| erichocean wrote:
| I'd do the second half of the book, it's got plenty of
| important techniques that aren't taught in the first half.
|
| Once you've done that, you can see how it's done "for real" in
| a production setting by reading the source code to Wren (by the
| same author). [0]
|
| Wren's implementation maps very closely to the C implementation
| of Lox.
|
| At that point, you're ready to do your own language. As far as
| compilation techniques go, you'll still be missing the "middle-
| end" of the compiler, which uses an SSA IR. I don't recommend
| implementing this yourself, I'd look into MLIR (from the LLVM
| project) if you want to actually work on the middle-end. You
| can create one or more dialects that are unique to your
| language, and implement your own compiler transformations.
| There are lots of existing papers and projects on GitHub
| demonstrating doing so.
|
| [0] https://wren.io/
| kwertzzz wrote:
| I am wondering why the julia lox interpreter is so slow. Could
| it be that there is a lot of type unstable code or could it be
| an issue with julia's garbage collector? (I can relate to the
| comment that it is quite hard to find usable information from
| julia's profiler).
| adgjlsfhk1 wrote:
| I'm pretty sure it is type instability. The faster way to do
| this would be with something like
| https://github.com/YingboMa/Unityper.jl which would fix that.
| The problem with profiling unstable code in Julia is that it
| makes everything slow so the profiler will just show a big
| mess of everything being slow. We do need better resources,
| but I have no idea what they would like like.
| flofriday wrote:
| I continued by taking a compilers and a interpreters course at
| my university. In the interpreters course a friend and I
| desinged a new language and implemented it. It turns out
| designing a language is pretty hard, but it was quite fun and
| am proud of the project. Also I really wanted to implement a
| typechecker, so we did that too.
|
| https://github.com/flofriday/Moose
| endgame wrote:
| I just finished the bytecode interpreter side, and I have
| similar questions. The next areas of interest for me are
| reasonable AST representations in C and learning how to
| translate a semantics from a PL paper to a runtime. Anyone have
| any recommendations?
| latenightcoding wrote:
| a fast lisp interpreter/compiler?
| sundarurfriend wrote:
| I thought working with the lossless syntax tree was the key to
| Rust's pin-point precise error messages. How does rust-analyzer
| get and print the specific point of error if it throws away the
| non-essential information before that stage? I suppose the
| position information is stored along with the Error nodes, in the
| original parsing?
| lukemerrick wrote:
| In general, if you keep the source code positions of every
| nontrivial token, and you keep the raw source code, then yeah
| you can print out those pretty specific point error messages
| regardless of whether you keep your trees lossless. Also, if
| you want to include filename in your messages (perhaps because
| unlike Lox your language supports imports), then you'll need
| more than just lossless trees to store the necessary
| information.
|
| I'm not sure exactly how Rust and rust-analyzer keep track of
| the info necessary to their excellent error messages and
| diagnostics, but I wouldn't be surprised if pinpoint messages
| were not the primary motivation for rust-analyzer to do
| lossless parsing.
| yeison wrote:
| Now we need a cream cheese interpreter and we'll be all set.
___________________________________________________________________
(page generated 2023-06-03 23:00 UTC)