Comment by jll29

I bought this book when I was working on a toy language and I think I was too stupid to understand most of it. The first few chapters were great, but it quickly surpassed my capacity to understand. Seeing it mentioned makes me want to revisit.

Another vote for Lisp in Small Pieces. Great high level compiler book that teaches you how to build a Lisp and doesn’t get bogged down in lexing and parsing.

Instead of Lisp in Small Pieces I'd recommend SICP instead. No continuation passing, but much better written.

Imo BNF (or some other formal notation) is quite useful for defining your syntax, my biggest gripe with BNF in particular is the way it handles operator precedence (through nested recursive expressions), which can get messy quite fast.

Pratt parsers dont even use this recursion, they only have a concept of 'binding strength', which means in laymans terms that if I'm parsing the left side of say a '' expression, and I managed to parse something a binary subexpression, and the next token I'm looking at is another binary op, do I continue parsing that subexpression, which will be the RHS of the '' expression, or do I finish my original expression which will then be the LHS of the new one?

It represents this through the concept of stickiness, with onesimple rule - the subexpression always sticks to the operator that's more sticky.

This is both quite easy to imagine, and easy to encode, as stickiness is just a number.

I think a simpler most straightforward notation that incorporates precedence would be better.

I would argue the opposite: Being describable in BNF is exactly the hallmark of sensible syntax in a language, and of a language easily amenable to recursive descent parsing. Wirth routinely published (E)BNF for the languages he designed.

The problem with recursive descent parsers is that they don't restrict you into using simple grammars.

But then, pushing regular languages theory into the curriculum, just to rush over it so you can use them for parsing is way worse.

It's been a few years since I worked with the dragon book, but I think the most common complaint was that it starts with like 350 pages on parser theory: generating bottom-up and top-down parsers from context free grammars, optimizing lexers for systems that don't have enough RAM to store an entire source file, etc... before ever getting to what most people who want to write a compiler care about (implementing type inference, optimizing intermediate representations, generating assembly code). Of course parsing is important, and very interesting to some. But there's a reason most modern resources skip over all of that and just make the reader write a recursive descent parser.

It’s academic and comprehensive, that’s the issue. It’s not about writing a production grade compiler, though, in my humble opinion. There are more things to learn for that, unfortunately… is just a pretty big topic with lots of stuff to learn.

The recommended advice is to start with semantics first. Syntax will change, there is not much point fixing it down too early.

Most of the work is actually the backend, and people sort of illusion themselves into "creating a language" just because they have an AST.

Getting an overview of parsing theory is mainly useful to avoid making ambiguous or otherwise hard to parse grammars. Usually one can't go too wrong with a hand-written recursive descent parser, and most general-purpose language are so complicated that parser generator can't really handle them. Anyway the really interesting parts of compiling happen in the backend.

Another alternative is basing the language on S-expressions, for which a parser is extremely simple to write.

Have no fear, we'll just train an LLM on TAOCP and have it automatically generate the remaining volumes‽

You'll want part 2 as well for a total of 107 pages.