Re: More detailed error messages when using yacc

thomas.bonk@web.de Date: 23 Jul 2000 17:02:16 -0400 said
<<But additionally I
would like to provide informations what the parser expected to read
instead of the wrong symbol it got.>>


You have not asked for a contrary opinion, but if you have time to
reconsider then maybe this will be useful.


Parsers are like parallel processors. At any given moment they might
have several 'expectations' that _could_ be met by the next token.


When a next token arrives some of those expectations remain alive and
progress to yet another next expectation in the sequence, other
expectations drop off.


It can be difficult to present a list of all the current-next
expectations at any given position (that is, it is merely hard
programmatically because it is open-ended, and in some grammars there
are nodes where there could be numerous legal next tokens).


But maybe more important, the user has only one thing in mind (if they
are clear at all), and your (potentially long) list of alternatives
could be very confusing.


So you are faced with a challenge, if you are to list out the
expectation, or just a few expectations, that would be a valid
continuation; where do you draw the line ... when there are as many as
four possible continuations do you then only present three, or do you
refuse to present the list in 'complex' (x > 4 ?) continuations?


Also, keep in mind that surprises are not just extras, they can be
excellerated collison with following matter when something is dropped
from an input text: for example; if you are in the position after b
...


a b . c


and you expected c, and you get d, as in


a b d


it may be not so useful to say that. If the user had intended


a anything b d


where
      b d
is the next sequence intended (and a legitimate one) and the
    a ......
was an incomplete text.


So, yes it would be nice if the tools handed you coding conveniences
to say things like, 'you dropped something here' or 'you inserted a
surprise here' and as you indicate 'expected this here'. But the
situation in the code you are parsing is non-trivial
sometimes. Simplistic error message technology can lead to aggravation
for the user of your tool.


The nature of the basic parsing technology allows you to artfully
project a very large number of next-expectations at any given
position. The view is contrary to the view you imply in your question,
but it can be believed that it is not constructive to list out those
numerous next-expectations for the user: they can be quite numerous
and in a number of cases completely unbelievable to the average user!


This is especially true if the error you are trapping is in amongst
several others and the parser has (unavoidably) gotten itself down to
some node that has no relation to what the user had intended. So the
next-expectation idea is an expansion point, and the likelihood of
more than one error in a sequence gives you a combinatoric effect. If
the user makes two errors in a row, they are almost certainly not
going to understand your second list of possible continuations.


So perhaps temper you notion of listing possible continuations when
errors are trapped.


Best wishes,


Robert Rayhawk
RKRayhawk@aol.com

Return to the comp.compilers page.
Search the comp.compilers archives again.