[vector_spaces]

This attitude bugs me a lot. It seems really common, especially in more recent texts about language design and implementation, that parsing is heavily de-emphasized to the point where practically nobody talks about it. See Essentials of Programming Languages by Friedman & Wand, the relevant sections in SICP, Programming Languages: Application & Interpretation (which goes so far as to call it a distraction).

I get that parsing is more of an implementation detail and doesn't really belong to the space-brained realm of language design per se, but it's a bit annoying that most texts refuse to give any space to the topic, and rely on your language being S-expression based or assume you're going to use a parser generator. Like, in the real world, even if one will never actually implement a fully-fledged programming language, you're still probably going to have to parse things sometimes. I would love a book that goes into detail about different parsing techniques and considers best practices and patterns and tradeoffs/design considerations -- would pay good money for that

It reminds me somewhat of the situation in analysis, where there are lots of theorems that aren't written down anywhere because literally every book states them as "easy" exercises. Maybe I'm looking in the wrong places, but I can't find much in the way of concrete guidance on implementing parsers. I'm aware of the beautiful series on parsing theory by Aho & Ullman ("The Theory of Parsing, Translation, and Compiling"), but those are more focused on theory rather than implementation

[cdcarter]

On the other hand, historically (and as the parent you're replying to points out), many compiler texts have spent a MAJORITY of their time on parsing, and rush through the actual interesting parts of compilation.

> I would love a book that goes into detail about different parsing techniques and considers best practices and patterns and tradeoffs/design considerations -- would pay good money for that

Terrence Parr's "Language Implementation Patterns" spends quite a bit of time on parsing, and parse tree->ast conversyions.

[vector_spaces]

Thanks for pointing that one out -- I had written that one off before as an ANTLR book but looks like it covers more material than I gave it credit for

[marssaxman]

> Like, in the real world, even if one will never actually implement a fully-fledged programming language, you're still probably going to have to parse things sometimes.

That is definitely true, but in practice there isn't much to say about it, because sophisticated parsers turn out not to be particularly important; it works out better overall to design simple grammars, and then the parsing is easy.

- If you're a beginner, you'll write a recursive descent parser, because that's the simplest technique, and it lets you focus on your project instead of a new, unfamiliar tool.

- If you're writing a domain-specific language, or a config format, or something of that nature, you'll use whichever parser generator integrates most conveniently into your workflow, and you'll design your grammar around whatever its manual tells you to do.

- If you're writing a full-scale language compiler, you'll go back to recursive descent, because that offers the easiest way to recover from errors and report informative messages. Maybe you'll throw in precedence-climbing for operators.

> I would love a book that goes into detail about different parsing techniques and considers best practices and patterns and tradeoffs/design considerations -- would pay good money for that

I would also read such a book, but it would be more of a book about parser generators than a book about parsers.