|Set of allowable next tokens firstname.lastname@example.org.Virginia.EDU (1991-01-11)|
|Set of allowable next tokens email@example.com (1991-01-11)|
|Re: Set of allowable next tokens firstname.lastname@example.org (1991-01-12)|
|Re: Set of allowable next tokens email@example.com (1991-01-14)|
|Re: Set of allowable next tokens firstname.lastname@example.org (1991-01-16)|
|Re: Set of allowable next tokens email@example.com (1991-01-15)|
|From:||firstname.lastname@example.org (Dave Jones)|
|Keywords:||yacc, parse, debug, errors|
|Organization:||Megatest Corporation, San Jose, Ca|
|Date:||16 Jan 91 02:37:19 GMT|
> 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
[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]
Return to the
Search the comp.compilers archives again.