Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uunet!world!iecc!compilers-sender
From: megatest!djones@decwrl.dec.com (Dave Jones)
Newsgroups: comp.compilers
Subject: Re: Set of allowable next tokens
Keywords: yacc, parse, debug, errors
Message-ID: <14876@goofy.megatest.UUCP>
Date: 16 Jan 91 02:37:19 GMT
References: <1991Jan14.123822.12203@nestroy.wu-wien.ac.at>
Sender: compilers-sender@iecc.cambridge.ma.us
Reply-To: megatest!djones@decwrl.dec.com (Dave Jones)
Organization: Megatest Corporation, San Jose, Ca
Lines: 29
Approved: compilers@iecc.cambridge.ma.us

> In the book 'Compiler Construction using Unix' by Schreiner & Friedman 
> (sorry, I don't have the book here at work, and I don't recall the
> publisher) a modification to yacc is described which prints the set of
> allowed tokens when encountering a syntax error. It's actually sufficient
> to modify the yaccpar file.
> 
> There is a tar file on a.cs.uiuc.edu in ~ftp/pub/friedman which contains the
> modified yaccpar file.

It's buggy. In fact, on any non-trivial grammar, it is likely to fail
very badly, omiting most of the legal tokens.

What the hack actually does is to print the tokens which could be
shifted at the time the compiler detected the error.  That is
not sufficient, for the reason I first pointed out in a letter to
comp.compilers, posted Feb. 23, 1989. Sorry, I don't have the article number.
The problem is that the parser is likely to have altered its state since
the last token-shift, (through "default reductions"), at times when
other tokens could have been shifted.

If anyone cares to see them, I still have a couple of counter-examples
on hand.
[Oops, right.  Since yacc may have taken some default reductions before
noticing an error, the set of allowable tokens in the state where it
notices the error need not have much to do with the state where the
error really occurred.  -John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.