Re: Yacc shift/reduce conflicts

Martyn Weiss wrote:
> program:
> statements
> ;
> statements:
> statement
> | statements semicolon
> | statements semicolon statement
> ;
> statement:
> someterminal
> ;
>
> yacc reports no conflicts, but it looks a bit clumsy to me. However,
> if I replace "someterminal" by "expression", which has a number of
> alternative definitions (simpleexpression, term, factor, etc) I
> immediately get a whole raft of shift/reduce conflicts, which leads me
> to think the simplified version above isn't the best way to express
> the "superfluous semicolons" point mentioned above.
>
> Can anyone suggest a better formulation of "statements" or explain how
> I go about getting rid of the s/r conflicts in the fuller version.


Yes, it's clumsy. It would be better to allow a statement to be empty,
like this:


program:
      statements
;
statements:
      statement
| statements semicolon statement
;
statement:
      /* nix */
| expression
;
expression:
      simpleExpression
| term
| factor
| ...
;


If this change causes conflicts, there are two possibilities:


1. your grammer already accepted empty statements, through a rule
subordinate to statement, In other words, you didn't have to make any
changes. For example:


term:
/* nix */
| TERMINAL
;


2. Some other rule that uses statement also accepts an empty result in
place of statement. A modification of that rule would probably fix
things. For example, given that statement has been modified to accept
an empty result, the last alternative in the following example can be
eliminated:


if:
IF expression statement
| IF expression statement else statement
| IF expression else statement
;


y.output (generated when using the -v option) will tell you what is
going on.


--
Scott Nicol
snicol@apk.net

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