4 ms·

I think the conventional wisdom is that parser generators make it hard(er) to produce useful error messages for users. There are some exceptions, for example: h

• pizza234 7y ago
  An interesting argument against that is: > There’s also some argument made by GCC and Clang teams that they can hand-tune a hand written- parser to get better error messages. I believe they can do such hand tuning and probably have. But that argument does not stop you from customizing the grammar for generated parser to do essentially the same thing, so I don’t buy it as a differentiator. This is an excerpt from an interesting Quora reply on the subject: https://www.quora.com/Are-there-many-established-programming-languages-that-use-a-handcrafted-parser-Why/answer/Ira-Baxter https://www.quora.com/Are-there-many-established-programming...
  • tom_mellior 7y ago
    Yes, given a sufficiently powerful parser generator (more powerful than Yacc), you can do that. That's also the point of the talk I linked. Ira Baxter makes a living out of selling proprietary technology based on GLR parsing. His opinion matters, but if there is no open source GLR parser generator available (is there? I don't know), the point he makes cannot apply to GCC or Clang.
    • mjos 7y ago
      I believe GNU Bison parser generator is capable of generating GLR parsers: https://www.gnu.org/software/bison/manual/html_node/GLR-Parsers.html https://www.gnu.org/software/bison/manual/html_node/GLR-Pars...
      • thosakwe 7y ago
        Oh wow, that's pretty cool, wish I had known about it before. Unfortunately flex and bison, when used together in C++, cause a lot of headache (unless you create an "adapter" class that wraps your Flex parser and pass that to Bison). :/
    • wostusername 7y ago
      You don't necessarily need something more powerful than Yacc. I think the point was that you can encode errors directly into your grammar. So for some language with semicolon statement separators you can do something like this: PROGRAM -> STATEMENT* STATEMENT -> IF-STATEMENT | ASSIGN-STATEMENT | STATEMENT-ERROR IF-STATEMENT -> ... ASSIGN-STATEMENT -> ... STATEMENT-ERROR -> TOKEN* SEMICOLON The idea being that if the if-statement and assignment statement rules fail you consume tokens until the next statement separator (semicolon in our case), produce an Error node in the AST and resume parsing the next statement. This allows your parser to actually catch multiple errors in one pass since it won't die the moment it encounters something it can't parse. After parsing you scan the AST and if it has any Error nodes you spit out the relevant error messages and exit. You can get as granular with the error rules as you want, although the more you add the more unwieldy the grammar becomes. Naturally doing this in practice is harder than it sounds. Tweaking the Error rules is hard. If you consume too much or too little input you will resume in a spot that can have no chance of ever succeeding, giving way to a cascade of parse errors. I think we've probably all seen a compiler spit out a couple of dozen error messages all stemming from a single root error like a missing closing parentheses or brace.