| (Author of the article here) > Many production compilers have hand-written parsers because of error reporting, not because of issues with parser-generator algorithms. Yes! I totally agree. Error reporting was one of the things I meant when I said that there is somethings "lacking with the algorithms we have today". > The generated parser will not gracefully report a mismatched number of parentheses! Instead, it will report that the user's input is not formatted as expected, which makes it hard for the user to understand what went wrong. I'm not sure if this is the best example. Ruby is using Bison for parsing and it's certainly able to detect a missing parenthesis: ruby -e 'p (1 + 2'
-e:1: syntax error, unexpected end-of-input, expecting ')'
Most parser algorithms have a concept for "currently expected characters/tokens" and can easily report this on an error.I also think that this will be more precise in Glush than in e.g. LR-based algorithms because Glush is following the grammar strictly top-down. It knows exactly which characters are allowed at any given moment. I have however not made an effort to make nice error messages so I don't know how well automatic error reporting would work and I don't feel comfortable making any concrete claims or promises. > It is possible to modify the grammar to look for this case specifically: Not sure if I see much value in manually adding such a case. This seems like a case that would be easily handled automatically (again: see Ruby above). > But now I've just polluted my once-pristine grammar file. And adding all of the necessary error checks throughout the grammar will really make things complicated. Well, if you want the equivalent error reporting in a hand-written parser you also need to add an equivalent amount of code. There are probably ways you can annotate a grammar to improve error reporting and I think it's a far more interesting solution to investigate. I haven't experimented with this yet, but I'd love to try to tackle it if I can find the time. |