Crafting Interpreters • Hacker News Board

Re: Crafting Interpreters

#31

Post by goodthink » Thu, Jan 15, 2026, 2:01 PM UTC

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/primordialsoup.html?snapshot=Amplefo...

Re: Crafting Interpreters

#32

Post by high_na_euv » Thu, Jan 15, 2026, 2:03 PM UTC

ceronman wrote: post #26

jokoon wrote: post #13

I stopped reading when he started using the visitor pattern

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?

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.

Re: Crafting Interpreters

#33

Post by papercrane » Thu, Jan 15, 2026, 2:13 PM UTC

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.

Re: Crafting Interpreters

#34

Post by wiseowise » Thu, Jan 15, 2026, 2:21 PM UTC

high_na_euv wrote: post #32

ceronman wrote: post #26

Earlier quoted context omitted.

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?

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.

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).

Re: Crafting Interpreters

#35

Post by wiseowise » Thu, Jan 15, 2026, 2:25 PM UTC

raymond_goo wrote: post #12

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

LLMs can write much better comments than you do, but for some reason you continue to write them. Why?

Re: Crafting Interpreters

#36

Post by wffurr » Thu, Jan 15, 2026, 2:29 PM UTC

high_na_euv wrote: post #32

ceronman wrote: post #26

Earlier quoted context omitted.

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?

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.

Exhaustive switch with tail-calling makes for a very fast and readable interpreter.

Re: Crafting Interpreters

#37

Post by bbaron63 » Thu, Jan 15, 2026, 2:32 PM UTC

papercrane wrote: post #33

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.

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.

Re: Crafting Interpreters

#38

Post by not-a-juggler » Thu, Jan 15, 2026, 2:40 PM UTC

cfors wrote: post #30

volemo wrote: post #19

Earlier quoted context omitted.

What’s bad about the visitor pattern? /gen

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 a…

https://news.ycombinator.com/item?id=44304648

Grug doesn't elaborate much, but here's the author's take in slightly more detail.

Re: Crafting Interpreters

#39

Post by [deleted] » Thu, Jan 15, 2026, 2:49 PM UTC

bbaron63 wrote: post #37

papercrane wrote: post #33

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.

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.

[deleted]

Re: Crafting Interpreters

#40

Post by torginus » Thu, Jan 15, 2026, 2:57 PM UTC

stevefan1999 wrote: post #3

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 o…

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.