Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Crafting Interpreters

craftinginterpreters.com

Post reply on HN
Print view View original

41–50 of 62 posts

Re: Crafting Interpreters

#41

Post by torginus »

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.

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.

Re: Crafting Interpreters

#42

Post by ceronman »

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.

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.

Re: Crafting Interpreters

#43

Post by incognito124 »

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

Re: Crafting Interpreters

#44

Post by etyp »

HarHarVeryFunny wrote: post #28
kevthecoder wrote: post #14

Earlier quoted context omitted.

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

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

Re: Crafting Interpreters

#45

Post by HarHarVeryFunny »

etyp wrote: post #44
HarHarVeryFunny wrote: post #28

Earlier quoted context omitted.

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

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.

Re: Crafting Interpreters

#48

Post by fuzztester »

roetlich wrote: post #29
fuzztester wrote: post #23

Earlier quoted context omitted.

Compiler doesn't match the title of the book.

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

Thanks.

Re: Crafting Interpreters

#49

Post by wduquette »

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.

Been there, did that, very much enjoy the result.
Post reply on HN