Live data from Hacker News

Crafting Interpreters

craftinginterpreters.com

31–40 of 193 posts

Re: Crafting Interpreters

#31
Since people are talking about other compiler resources, one I have enjoyed so far though I still need to finish it, Immo Landwerth writing a compiler in c# that generates IL and also debug symbols and the like. It is older (about 5 years, so Core but like 3ish timeframe I believe) so doesn't use current c# syntax but shouldn't matter much for most of what you'd be doing other than a lot of warnings about nullability on types.

https://www.youtube.com/playlist?list=PLRAdsfhKI4OWNOSfS7EUu...

Re: Crafting Interpreters

#32
post #30

Earlier quoted context omitted.

Does a single production compiler use lex and yacc to generate any part of their system, beyond maybe a first pass to test out syntax before it gets rewritten into a hand written parser/lexer? I'm not going to say none exist since I don't know literally every production compiler ever written, but I have never heard of one that used them for the final code.

I think Ruby does? IIRC its source code includes a 10,000+ line “parse.y” file which is converted to C code using Yacc.

Interesting, I'll have to look into this because I'd never heard that before and now I'm curious.

A language with as much going on as Ruby was not one I would have picked as a candidate for yacc

Re: Crafting Interpreters

#33
post #30

Earlier quoted context omitted.

Does a single production compiler use lex and yacc to generate any part of their system, beyond maybe a first pass to test out syntax before it gets rewritten into a hand written parser/lexer? I'm not going to say none exist since I don't know literally every production compiler ever written, but I have never heard of one that used them for the final code.

I think Ruby does? IIRC its source code includes a 10,000+ line “parse.y” file which is converted to C code using Yacc.

Just went and looked in the github repo. 16,000+ line .y file. I can't imagine that is pleasant to maintain.

Re: Crafting Interpreters

#34
post #24

Planning to read this soon. Anyone got any other compiler book recommendations? Preferably modern (I've heard the dragon book is out of date)

Engineering a Compiler (Cooper and Torczon) seems to be widely recommended. I’ve got the second edition but there’s now a third - not sure how significant the changes are. AFAIK the problem with the dragon book is the same as with most academic compiler courses. It spends most of its time on the theory-heavy front-end (parsing) and much less on the back-end (code generation). Real-world compilers are very much the op…

I think Engineering a Compiler is a great next step after Crafting Interpreters. It's both easier to get into (in terms of writing style and structure) and, as you say, generally more practical than the Dragon Book.

Re: Crafting Interpreters

#36
post #10

The lex and yacc utilities are part of POSIX.2; is there any reason not to reach for them first? https://pubs.opengroup.org/onlinepubs/9699919799/utilities/l... https://pubs.opengroup.org/onlinepubs/9699919799/utilities/y... All the POSIX.2 standards for shell utilities can be found here: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ The original introduction to lex and yacc was in the book by Kernigan…

Parser generators create more problems than they solve.

Re: Crafting Interpreters

#37
post #10

The lex and yacc utilities are part of POSIX.2; is there any reason not to reach for them first? https://pubs.opengroup.org/onlinepubs/9699919799/utilities/l... https://pubs.opengroup.org/onlinepubs/9699919799/utilities/y... All the POSIX.2 standards for shell utilities can be found here: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ The original introduction to lex and yacc was in the book by Kernigan…

As the author of a POSIX standard utility, I would advise you to only reach for such utilities when portability is the most important thing. POSIX utilities are not great. Lex and Yacc included.

Are POSIX utilities even portable? They tend to have poor windows support. And they also tend to target C, which has a high ceiling for portability, but also a high bar for making things portable (whereas more modern languages are often just portable by default).

My take on POSIX utilities would be only to use them on Linux platforms where they effectively form a "native" part of the platform.

Re: Crafting Interpreters

#39

I really wish this book used something other than Java. Nothing against Java - just that I don't know it and don't feel excited about learning it.

For what it's worth, these days you could use an LLM to turn each code snippet into many other languages.

Or just focus on his words and use the snippets like generic code and figure out how to do it in whatever language of choice.

You don't need to "learn java" to become conversant or read it as pseudocode.

Re: Crafting Interpreters

#40

Earlier quoted context omitted.

As the author of a POSIX standard utility, I would advise you to only reach for such utilities when portability is the most important thing. POSIX utilities are not great. Lex and Yacc included.

Are POSIX utilities even portable? They tend to have poor windows support. And they also tend to target C, which has a high ceiling for portability, but also a high bar for making things portable (whereas more modern languages are often just portable by default). My take on POSIX utilities would be only to use them on Linux platforms where they effectively form a "native" part of the platform.

I was mostly speaking about POSIX, since that was the focus of GGP.

Yes, you should only use them on POSIX.

My utility does build natively on Windows, though.

Post reply on HN