3 ms·
Error messages and error recovery are to some extent red herrings. You really do not want a production system to accept wrong inputs (and especially not try to
by jbangert 11y ago
Error messages and error recovery are to some extent red herrings. You really do not want a production system to accept wrong inputs (and especially not try to 'recover' them into a usable parse tree). This will definitely make your parser ambiguous and can have very real security implications (say, microsofts anti-xss transformations introducing XSS).
As to LL1 - many real world protocols can't be parsed efficiently as LL1.
- Nitramp 11y agoError messages really are core feature of parsers. Would you want SQLite to just "return false" whenever there was some syntactical error somewhere in your query? With error recovery in the context of a parser I mean the ability to continue parsing with predictable results after encountering an error. This is not about automagically correcting errors, it's about being able to report more than one error to the user. Returning just the first error encountered sucks, as does returning a slew of non errors caused by your parser getting messed up. As to LL1 - many real world protocols can't be parsed efficiently as LL1. Not sure what you mean with efficiently - a language either can or cannot be parsed as LL(1) because it's in that language class or not. But in any case, it's still very straightforward to make LL decisions with a longer lookahead in hand-written code, and the decision code is often more efficient than what a generator would create.