Re: Error reporting/recovery

    iank@bearcave.com (Ian Kaplan) wrote:
> Jean-Marc Bourguet <bourguet@my-deja.com> wrote:
> > The parser generators I know of (I've looked at yacc variants and
> > pccts) are bad at error reporting/recovery at least when not helped
> > by suitable addition in the grammar description. I know that the
> > field has been studied and I'm quite sure that yacc is not at the
> > state of the art in this matter, so I wondered:
> > - if there was other parser generators freely available
> > who did a better jobs,
> > - if there was an available benchmark (grammars and
> > input) to test the error reporting/recovery of parser
> > generators.
>
> I use ANTLR, which has excellent error reporting "right out of the box".


Is the ANTLR error reporting different from the one of PCCTS? As far
as I known, the out of the box error reporting of PCCTS is just the
list of valid tokens (with help, it may summarize some sets of token
by a name like "relationnal operator"). That is not something I'd
call excellent but just minimal.


I fear that providing what I'd call excellent error messages you need
to take semantic into account and use heuristic. (The difference
between very good and excellent error messages is tiny, reporting a
missing end token using the same case as the user do ie. report using
'END' 'End' or 'end' would make a very good error message an excellent
one).


> ANTLR generates a recursive decent parser, which tends to have
> beeter error reporting.


It is easier to do a simple error reporting for a recursive decent
parser (and then for an LL grammar I'm not sure is it really simpler),
but I remember having read something on a parser generator which gave
meaningfull error messages in the case of unclosed recursive structure
(like begin/end block, parenthized expressions). For this kind of
processing, I wonder if the LR states may provide better hints on what
is expected.


-- Jean-Marc Bourguet

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