Hacker News Reader

Comment by jokoon | Hacker News Reader

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.

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

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

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.

C# doesnt have exhaustive switch over enums.

It needs to get "closed enum" lang. feature.

Exhaustive enums (or type switches) are not a requirement, and are infact harmful - imagine if they add a new kind of syntax node to the language, now your analyzer no longer compiles unless you add a default case - which is very easy to add in C# as well.

Unless you add default... or handle such case, as expected.

Ofc you can use this feature wrong and abuse default case, but in general this is very good since it prevents you about missing places to add handling and screams at you at comp time instead of runtimr

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.

The bytecode interpreter in the second half of the book doesn't use the visitor pattern.

the parser does

I’ve only glanced at the second part but I don’t remember that being the case.

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.

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

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

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.

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

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

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

Why?

Reply on news.ycombinator.com