[HN Gopher] Crafting Interpreters
___________________________________________________________________
Crafting Interpreters
Author : tosh
Score : 225 points
Date : 2026-01-14 22:26 UTC (1 days ago)
(HTM) web link (craftinginterpreters.com)
(TXT) w3m dump (craftinginterpreters.com)
| azhenley wrote:
| The two most popular discussions of this fantastic book:
|
| 2020 with 777 points:
| https://news.ycombinator.com/item?id=22788738
|
| 2024 with 607 points:
| https://news.ycombinator.com/item?id=40950235
| stevefan1999 wrote:
| Really I would love to know how parse context sensitive stuff
| like typedef which will have "switched" syntax for some tokens.
| Would like to know things like "hoisting" in C++, where you can
| you the class and struct after the code inside the function too,
| but I just find it hard to describe them in rigorous formal
| language and grammar.
|
| Hacky solution for PEG such as adding a context stack requires
| careful management of the entry/exit point, but the more
| fundamental problem is that you still can't "switch" syntax, or
| you have to add all possible syntax combination depending on the
| numbers of such stacks. I believe persistent data structure and
| transactional data structure would help but I just couldn't find
| a formalism for that.
| remexre wrote:
| https://en.wikipedia.org/wiki/Lexer_hack
|
| Make your parser call back into your lexer, so it can pass
| state to it; make the set of type names available to it.
| torginus wrote:
| C/C++ has one of the worst-designed syntaxes, its such a shame
| that entire families of the most popular languages ended up
| copying the same mistakes.
|
| I know it's no solace to you, but Rust and Go don't even have
| this problem Afaik, and it's avoidable by careful
| consideration.
| luksenburg wrote:
| Another possible solution is the usage of functional parsers
| (e.g.: [0]) and making use of some form of the 'do' notation.
| Each step makes its result available to all subsequent parsers.
|
| [0] https://hackage.haskell.org/package/parsec
| rohitpaulk wrote:
| In case anyone finds it useful, we (CodeCrafters) built a coding
| challenge as a companion to this book. The official repository
| for the book made this very easy to do since it has tests for
| each individual chapter.
|
| Link: https://app.codecrafters.io/courses/interpreter/overview
| mi_lk wrote:
| Not sure why this ad (access needs paid membership) is the top
| comment
| Nora23 wrote:
| One of the best resources for learning compiler design. The web
| version being free is incredibly generous.
| fuzztester wrote:
| Compiler doesn't match the title of the book.
| roetlich wrote:
| Well, most interpreters use a compiler internally, for
| example to compile to byte code. The book explains that as
| well, so I'd recommend just reading it:
| https://craftinginterpreters.com/a-map-of-the-
| territory.html...
| fuzztester wrote:
| Thanks.
| Me1000 wrote:
| You should read the book! :)
| fuzztester wrote:
| I had started but not come to that point yet. Mea culpa.
| chrysoprace wrote:
| I've found this book to be a good way to learn a new language,
| because it forces you to do a bit of reading about various
| language features and patterns to create equivalent
| implementations. For languages that lack some of the features in
| Java, it can be tricky to learn how to apply similar patterns,
| but that's half the fun (for me).
| acedTrex wrote:
| I have bought the print version of this 3 seperate times to give
| as a gift, its excellent.
| munificent wrote:
| Thank you for buying copies! :D
| keyle wrote:
| It's a great book, I bought the paper version first, but man it
| was too big and heavy for my liking, ended up buying a digital
| copy; much more practical for notes and search...
|
| although I keep getting lost somewhere in the mountain :)
|
| I also recommend munificent's other book about game programming
| patterns. Both are fun to read.
| flir wrote:
| Sometimes I get the spine guillotined off and replaced with a
| ring binding. Any print shop can do it for you, and you just
| lose the gutter plus a little margin. Easier to work with at a
| desk, and you can even split into two "books" if you feel it
| necessary.
|
| But that's only for books I don't want to keep, and Crafting
| Interpreters is definitely a keeper...
| keyle wrote:
| Interesting idea. Thanks.
| kunley wrote:
| Part of a 2nd half of this book translated to Go became a
| skeleton for the BCL configuration language
| https://github.com/wkhere/bcl
| raymond_goo wrote:
| Crafting Interpreters is the one thing that LLM's can do really
| really well. Because it is so easy to define and test.
|
| Here are is a new LUA interpreter implemented in Python:
|
| https://github.com/rhulha/MoonPie
|
| And here is a new language:
|
| https://github.com/rhulha/EasyScript
| nicoburns wrote:
| > Because it is so easy to define and test
|
| Probably also because there 100+ implementations for it to copy
| from
| ramon156 wrote:
| What even is the point of that? The whole point of the book is
| to get a sense and mindset of crafting compilers.
| HarHarVeryFunny wrote:
| Is MoonPie your project? Have you written up anything about
| your experience and process of creating it?
| wiseowise wrote:
| LLMs can write much better comments than you do, but for some
| reason you continue to write them. Why?
| jokoon wrote:
| I stopped reading when he started using the visitor pattern
| kevthecoder wrote:
| The bytecode interpreter in the second half of the book doesn't
| use the visitor pattern.
| jokoon wrote:
| the parser does
| tonyedgecombe wrote:
| I've only glanced at the second part but I don't remember
| that being the case.
| ceronman wrote:
| The parsers in crafting interpreters do not use the visitor
| pattern. The visitor pattern is used when you already have
| a tree structure or similar. The parser is what gives you
| such tree structure, the AST. When you have this structure,
| you typically use the visitor pattern to process it for
| semantic analysis, code generation, etc.
| HarHarVeryFunny wrote:
| No, but his first "Tree-walk Interpreter" does - he builds an
| AST then uses the visitor pattern to interpret it.
|
| https://craftinginterpreters.com/representing-
| code.html#work...
| etyp wrote:
| To quote the very first paragraph of the bytecode
| interpreter section[1]:
|
| > The style of interpretation it uses--walking the AST
| directly--is good enough for some real-world uses, but
| leaves a lot to be desired for a general-purpose scripting
| language.
|
| Sometimes it's useful to teach progressively, using
| techniques that were used more often and aren't as much
| anymore, rather than firehosing a low-level bytecode at
| people.
|
| [1] https://craftinginterpreters.com/a-bytecode-virtual-
| machine....
| HarHarVeryFunny wrote:
| Sure, I'm not criticizing it.
|
| He's doesn't actually build on this though, but rather
| goes back to a single pass compiler (no AST, no visitor)
| for his bytecode compiler.
| volemo wrote:
| What's bad about the visitor pattern? /gen
| cfors wrote:
| https://grugbrain.dev/
|
| _grug very elated find big brain developer Bob Nystrom
| redeem the big brain tribe and write excellent book on
| recursive descent: Crafting Interpreters_
|
| _book available online free, but grug highly recommend all
| interested grugs purchase book on general principle, provide
| much big brain advice and grug love book very much except
| visitor pattern (trap!)_
|
| Grug says bad.
|
| In all seriousness, the rough argument is that it's a "big
| brain" way of thinking. It sounds great on paper, but is
| often times not the easiest machinery to have to manage when
| there are simpler options (e.g. just add a method).
| not-a-juggler wrote:
| https://news.ycombinator.com/item?id=44304648
|
| Grug doesn't elaborate much, but here's the author's take
| in slightly more detail.
| fuzztester wrote:
| Why?
| ceronman wrote:
| The visitor pattern is very common in programming language
| implementations. I've seen it in the Rust compiler, in the Java
| Compiler, in the Go compiler and in the Roslyn C# compiler.
| Also used extensively in JetBrains' IDEs.
|
| What do you have against this pattern? Or what is a better
| alternative?
| high_na_euv wrote:
| Visitor is heavy of code pattern that can be replaced by
| elegant, readable switch with exhaustive check, so all
| operations available by "Kind" enum are covered.
| wiseowise wrote:
| This wasn't available in Javs at the time. You're free to
| rewrite it with pattern matching (like the book, quite
| literally, leaves as an exercise for the reader).
| wffurr wrote:
| Exhaustive switch with tail-calling makes for a _very fast_
| and readable interpreter.
| torginus wrote:
| Roslyn has visitor pattern combined with the 'Kind'
| enumeration you mentioned. You can either choose to visiti
| a SyntaxNode of a certain type, or override the generic
| version and decide what you want to do based on that
| enumeration.
| ceronman wrote:
| A switch or pattern matching approach is useful, but not
| practical for some cases. For example, there are cases
| where you are interested in only a single kind of node in
| the three, for those cases the Visitor pattern is very
| helpful, while doing pattern matching is cumbersome because
| you have to match and check almost every node kind. That's
| why, for example, the Rust compiler still uses the visitor
| pattern for certain things, and pattern matching for
| others.
| goodthink wrote:
| Reading this book brought me a better understanding of "the
| expression problem" and the use of the visitor pattern as its
| solution. This led me to (finally) grok the use of Class
| _Heirarchy_ Inheritance[0] as a solution not requiring visitors.
| In Newspeak[1], classes can contain nested classes, so when you
| subclass a class, you inherit the nested classes as well. This
| blog post discusses the same feature affording Free Object
| Algebras [2].
|
| [0]
| https://blog.bracha.org/primordialsoup.html?snapshot=Amplefo...
| [1]https://newspeaklanguage.org [2]https://blog.bracha.org/primor
| dialsoup.html?snapshot=Amplefo...
| papercrane wrote:
| I love this book! I do wish there was a new edition that updated
| the version of Java used in the tree-walk interpreter. There's
| been some additions to the language, like sealed classes and
| exhaustive switches, that could really benefit the
| implementation.
| bbaron63 wrote:
| It's a fun little exercise left to the reader to upgrade to
| current Java. It pretty much eliminates the need for his ad-hoc
| code generation tool.
| wduquette wrote:
| Been there, did that, very much enjoy the result.
| incognito124 wrote:
| I just went through this book during the winter holidays. I just
| love the author's casual writing style and all the tiny jokes and
| puns they made.
|
| I hope we get to see "Add a type checker to Lox" sequel
| wduquette wrote:
| Simply my favorite programming text of all time.
| codr7 wrote:
| I'll just drop this here for those looking to get started on
| interpreters:
|
| https://github.com/codr7/shi
|
| And perhaps this for those leaning towards C:
|
| https://github.com/codr7/hacktical-c
___________________________________________________________________
(page generated 2026-01-15 23:01 UTC)