3 ms·
The historical reason was error recovery and error messages. It is a solved problem now, you can have it all with generated PEG parsers.
by sklogic 11y ago
The historical reason was error recovery and error messages. It is a solved problem now, you can have it all with generated PEG parsers.
- jstimpfle 11y agoAlarm bells ring in my head whenever someone claims "it's a solved problem" in the context of an engineering (as opposed to mathsy) problem. Unless the context is really narrow (and the problem becomes basically a math problem) that claim is usually wrong. Thanks for pointing to PEGs. I will definitely try them out. But judging from a quick web search, it's obvious that there are perfectly valid reasons not to use a PEG grammar today -- unless someone already designed the grammar for you (and it's PEG!). http://lambda-the-ultimate.org/node/3039#comment-44356 http://lambda-the-ultimate.org/node/3039#comment-44356 http://stackoverflow.com/questions/1857022/limitations-of-peg-grammar-parser-generators http://stackoverflow.com/questions/1857022/limitations-of-pe... Those of us who care about syntax (that is optimized for the user, not the programmer), will have to keep thinking about parsers for the foreseeable future.
- sklogic 11y agoPEG is basically a thin abstraction over recursive descent parsing. Everything you can do in a handwritten parser can be expressed mostly declaratively in PEG. And, no, there is no single reason not to use PEG. Especially when the choice is between a handwritten parser and a PEG. There is a lot of stupid FUD about PEGs, you should ignore it. Your links are pointing to the ignorant, incompetent mumbling of those who never tried implementing a proper PEG. And I never met a language for which writing a PEG parser was not totally trivial. A pro tip: use PEG alongside with a Pratt for the binary expressions.