On Mon, Jul 09, 2018 at 10:04:35AM +0200, Otto Moerbeek wrote:
Hello Otto,
>> I still don't see the point. In 30 years, I've gotten by with parsers
>> that say "syntax error", and had very bad experiences with programs that
>> do a poor job anticipating where the parse error is. Of course there are
>> programs which do a good job of detecting the error, but generally those
>> don't use yacc...
> I'm not trying to guess anything. yacc uses one-token lookahead. If it
> cannot continue, the lexical value of the token that could not be processed
> gives a pretty clear indication of the error spot.
We can state something even a little stronger than that. An LR parser (such
as Yacc) will always stop at the first possible point an error can be
guaranteed to have occurred. Often that point is the same as where the error
was made (e.g. "x = 1 + ;" will report an error at the semi-colon), although
sometimes it isn't (a simple example is "fi (x) { ... }": the error will be
reported at the open curly, even though a human would consider the error to
have occurred at "fi"). In my opinion, when the error location is correct
it's a genuine help (and, in practise, most errors seem to fall into this
category); when it's wrong, it tends to be very obvious, and you're in no
worse a situation than you were if it just says "syntax error".
[My personal opinion is that a lot of the ill feeling towards error recovery
is to do with when it gets it wrong, tries to keep on parsing, and fills the
terminal up with incorrect errors -- the cascading error problem. Anyone with
too much time on their hands can read my attempted solutions to that at
https://arxiv.org/abs/1804.07133]
Laurie
--
Personal http://tratt.net/laurie/
Software Development Team http://soft-dev.org/
https://github.com/ltratt http://twitter.com/laurencetratt
