51–60 of 193 posts
I know this book has been praised before on HN, but I've been personally a bit disappointed. It's suitable for someone with no very little knowledge on the topic, but it doesn't really cover any advanced topic.
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.
[0]: https://github.com/ruby/prism
[1]: https://railsatscale.com/2023-06-12-rewriting-the-ruby-parse...
Earlier quoted context omitted.
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.
Also I did some searching to see past discussions of Engineering a Compiler and found this interesting comment thread from Bob Nystrom for anyone interested: https://news.ycombinator.com/item?id=21725581
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.
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.
I guess if you're extremely early in your career and have never written anything but Python, it might not be, but if you've ever touched any statically-typed language and a language with a somewhat C-like syntax, you should be fine.
Earlier quoted context omitted.
It doesn't have to be a crazy amount of work, see Lisp-in-Lisp in the original SCIP book or a lambda calculus interpreter in Haskell (fits on a screen).
L-in-L interpreters assume that you already have symbols implemented, memory management implemented, reader and printer implemented, ... You could spend considerably more time implementing a Lisp dialect's math library than the interpreter. There are a lot of combinations. Where are the objects, hash tables, exception handling, ... Of course you can get some of these things from a host language, but someone had to ma…
Mad respect to those with that kind of dedication, and everyone working to keep all the dev infrastructure going, but I'm super glad my "I want to make a language" phase was just a passing interest! That's just a crazy amount of work!
It doesn't have to be a crazy amount of work, see Lisp-in-Lisp in the original SCIP book or a lambda calculus interpreter in Haskell (fits on a screen).
Earlier quoted context omitted.
L-in-L interpreters assume that you already have symbols implemented, memory management implemented, reader and printer implemented, ... You could spend considerably more time implementing a Lisp dialect's math library than the interpreter. There are a lot of combinations. Where are the objects, hash tables, exception handling, ... Of course you can get some of these things from a host language, but someone had to ma…
Yes but my point is that these problems are as hard as we want to make them. For a simple language implemented in C, maybe it's fine to never free any memory until the process quits.
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…
> We will abstain from using [parser generators] here. I want to ensure there are no dark corners where magic and confusion can hide, so we’ll write everything by hand. As you’ll see, it’s not as bad as it sounds, and it means you really will understand each line of code and how both interpreters work.
^ https://craftinginterpreters.com/introduction.html#the-code