I'm writing a grammar in YACC (actually Bison), and I'm having a shift/reduce problem. It results from including the postfix increment and decrement operators. Here is a trimmed down version of the grammar:
%token NUMBER ID INC DEC
%left '+' '-'
%left '*' '/'
%right PREINC
%left POSTINC
%%
expr: NUMBER
| ID
| expr '+' expr
| expr '-' expr
| expr '*' expr
| expr '/' expr
| INC expr %prec PREINC
| DEC expr %prec PREINC
| expr INC %prec POSTINC
| expr DEC %prec POSTINC
| '(' expr ')'
;
%%
Bison tells me there are 12 shift/reduce conflicts, but if I comment out the lines for the postfix increment and decrement, it works fine. Does anyone know how to fix this conflict? At this point, I'm considering moving to an LL(k) parser generator, which makes it much easier, but LALR grammars have always seemed much more natural to write. I'm also considering GLR, but I don't know of any good C/C++ GLR parser generators.
This basic problem is that you don't have a precedence for the
INC
andDEC
tokens, so it doesn't know how to resolve ambiguities involving a lookahead ofINC
orDEC
. If you addat the end of the precedence list (you want unaries to be higher precedence and postfix higher than prefix), it will fix it, and you can even get rid of all the
PREINC
/POSTINC
stuff, as it's irrelevant.Bison/Yacc can generate a GLR parser if you specify
%glr-parser
in the option section.Try this:
The key is to declare postfix operators as non associative. Otherwise you would be able to
The parenthesis also need to be given a precedence to minimize shift/reduce warnings
preincrement and postincrement operators have nonassoc so define that in the precedence section and in the rules make the precedence of these operators high by using
%prec
I like to define more items. You shouldn't need the %left, %right, %prec stuff.
Play around with this approach.