(no title)
brmgb | 2 years ago
> I tend to prefer hand written parsers, either via a combinator library or fully manually.
That’s common with people used to languages which provide poor parser generators.
brmgb | 2 years ago
> I tend to prefer hand written parsers, either via a combinator library or fully manually.
That’s common with people used to languages which provide poor parser generators.
hardwaregeek|2 years ago
I don’t know of many production compilers that use parser generators
klodolph|2 years ago
If you know the language, and you have a bunch of users, and you are writing a parser for it, by all means, write a parser by hand and give it the best error recovery that you can muster. If you are developing a language and want to do a bunch of experiments, it pays dividends to use a parser generator. And then there is the whole space of DSLs and mini-languages you encounter, where beautiful error messages are a nice-to-have, but you would rather ship a generated parser and move on to more important work.
It’s easy to focus on compilers from the perspective of familiar languages like writing compilers for Rust or for OCaml, but you may end up writing a compiler that gets used by a much smaller number of people, for smaller tasks.
derriz|2 years ago
Simple to write, debug, recover from errors, provide decent error messages, unit test, integrate into build systems, IDEs etc.
I also believe that nearly all the popular compilers these days do something similar - gcc was rewritten a few years ago in this fashion because of the technical benefits I’ve listed above.
moomin|2 years ago
59nadir|2 years ago
The vast majority of real languages have hand-rolled parsers and there is no real reason they shouldn't.
foderking|2 years ago
lmao