3 ms·
A good LL(1) parser generator will be able to provide helpful error messages and good performance, at the cost of not being able to parse all grammars you might
by YorickPeterse 11y ago
A good LL(1) parser generator will be able to provide helpful error messages and good performance, at the cost of not being able to parse all grammars you might come up with.
- sklogic 11y agoLL(1) cannot recover that easily, which makes error reporting less useful.
- YorickPeterse 11y agoThis depends on the parser implementation. For example, https://github.com/yorickpeterse/ruby-ll https://github.com/yorickpeterse/ruby-ll lets you customize the error messages as the default ones can be a little bit confusing at times. An example of this is https://github.com/YorickPeterse/oga/blob/0fd6fd8645e57ea4b2c29264d498b9bccbb43a04/lib/oga/xml/parser.rll#L268-L284 https://github.com/YorickPeterse/oga/blob/0fd6fd8645e57ea4b2... which changes messages from "unexpected T_FOO, expected T_BAR" to "unexpected end of input, expected element closing tag". Having said that, a hand written parser _will_ beat LL(1) (or any parser generator for that matter) when it comes to error reporting, though this depends on the amount of effort a programmer put in to the error reporting.
- sklogic 11y agoI'm talking about the recovery, not the messages - things like "skip to the next ';' and continue parsing a statement". > or any parser generator for that matter PEG-based generators can be just as good as handcrafted ones.
- yxhuvud 11y agoAs can Earley based ones, since the full parsing state is available (and, for that matter - possible to modify. It is quite possible to make up rules as you go).