craftinginterpreters

'Crafting Interpreters' is Bob Nystrom's book that teaches you how to build a compiler from scratch. It is an excellent resource and I can highly recommend it. Really light to read and walks you through all the concepts step-by-step. The first part of the book builds a compiler for the 'Lox' toy language in Java. While I have nothing against Java, personally I have never used it much so I decided to go through the first part of the book writing the code snippets in Python, a language I'm more familiar with. My implementation is probably not remarkable against the list of other implementations (https://github.com/munificent/craftinginterpreters/wiki/Lox-...), though I tried to minimize the amount of 'object oriented' language features in Python that I use. The AST is also stored 'flat' as a list. Personally I find this style of code much e

An optional challenge gives an implementation of arrays for jlox at least: https://github.com/munificent/craftinginterpreters/blob/4a84...

It's not too hard to adapt the first half of the book into whatever language you want. People have posted versions in dozens of languages: https://github.com/munificent/craftinginterpreters/wiki/Lox-... (There are fewer options for the second half, since you need more control over memory management.)

Cool! I did not know about that book. Added to [1]. :-) -- 1: https://github.com/munificent/craftinginterpreters/issues/92...

> If you’ve been relying on Markdown and occasionally fighting its quirks, AsciiDoc might be the structured, fully-featured alternative you didn’t know you needed. No, I'm afraid it's the format I know I don't need. At least not for the kind of things I usually use markdown for. Readme files, technical documentation, moderately complex websites with templating and rendering engines - markdown works just fine. Sometimes with a custom `|||warning\n...\n|||\n` thrown in to render something in a box with a red border. I get that there's a market in the space occupied by TeX, Typst (underrated IMHO), and possibly MS Word or Quark Express (for non-techies). Libreoffice is great in theory but, again IMHO, "eh" in practice. That market is generating book-length documents with all the cross-references and other features that needs. That said, Robe

The past few weeks I've been working on an implementation of DuckyScript3 used for keystroke injections attacks. See [1] for the official RubberDucky USB key page. My goal is to write a python interpreter to port as much commands as possible to run them on a RaspberryPi pico. It's a fun side project that I've loved working on lately. If you have any questions, feel free to ask. As mentioned in the README of the project, I am in no way affiliated with Hack5, which is the creator of the original USB RubberDucky and the DuckyScript language. Here is a link to another project on this topic, [2] which inspired me for doing this. At first I tried to contribute to this project but I got no answers from the owner and the way the code was written didn't correspond to the way I would have done it, so it gave me the motivation to create my own. I've

The license is here: https://github.com/munificent/craftinginterpreters/blob/mast... Though now that I look at it, I apparently completely forgot to specify how the images should be licensed. Oops. It's not a big deal and I really appreciate you reading and writing about the book, but I would prefer to not have the images reused without attribution.

There are a whole pile of Lox implementations in Rust (as well as many other lanugages): https://github.com/munificent/craftinginterpreters/wiki/Lox-...

Fun writeup. When I went through and implement the book in rust (https://github.com/jcdavis/rulox), I just used Rc and never really solved the cycle issue. I'll +1 and say I highly recommend going through Crafting Interpreters, particularly as a way of building non-trivial programs in languages you are less familiar with - If you just follow the java/C example you are tempted to lean into copy/pasting the samples, but figuring things out in other languages is a great experience. I spent a longass time tracking down an issue with how the reference interpreter implementation defines tokens: https://github.com/munificent/craftinginterpreters/issues/11... which was frustrating but good debugging practice.

Lots of people have done implementations in other languages: https://github.com/munificent/craftinginterpreters/wiki/Lox-... I did the first half in Clojure (in order to teach myself Clojure), worked just fine. I had to do a bit of translation but it's really not a lot.

I’m guessing you’ll have to work with the scopes in the resolver: https://github.com/munificent/craftinginterpreters/blob/mast...

I was asking this myself this while reading the book "Crafting Interpreters". I posted a few resources I found on an issue about implementing debuggers [1] -- although honestly I still haven't gotten down to read all of them (or to implement a debugger! :-/). -- 1: https://github.com/munificent/craftinginterpreters/issues/92...

I really look forward to reading the book myself, and don't have a background in compilation, but will probably try using my own language of choice for the first half anyways, because I feel I know what I want and no one can stop me :p > Second, because it's so large and packed already, the author left quite a few things out, particularly testing. There's precious little actual Lox code in the book, and no testing strategy. Testing interpreters well is relatively easy and very powerful, especially when implementing multiple ones for the same language. I do understand the space constraints, however. It's worth mentioning that the author does have a repo containing the tests they used while creating the book, which can be ran against the state of each interpreters (including your own) at the end of each chapter, which is really cool: https:

I love the crafting interpreters book, https://github.com/munificent/craftinginterpreters

I am not sure it really is literate programming, in the traditional sense. In literate programming source code and text are intertwined while Crafting Interpreters keeps code aligned to text but they are distinct https://github.com/munificent/craftinginterpreters EDIT: BTW the book is great, can't recommend it enough! :)