Re: bison shift/reduce conflict

[Jan-Henrik Haukeland]

Martin Pala <address@hidden> writes:

> Hi,
> 
> i looked on parser conflicts on present cvs version:
> 
> bison -y -dt p.y
> conflicts:  4 shift/reduce
> 
> I'm not very experienced in flex/bison and i'm not able to solve it
> now (without study of bison princips). Even though these warnings, it
> works well and as i saw in the documentation, it is possible to hide
> these warnings for predictable "non-dangerous" conflicts by specifing:
> 
> 
> %expect 4

That's one solution, although a bit rough since it just says; "If
there are excately 4 conflicts hide them" Another option is to fix the
problem. This is the problem:

timestamp       : TIMESTAMP PATH operator NUMBER time . action 

When the parser state reach the dot '.' should it reduce the timestamp
statement or shift and read the action statement before it reduces?

Since both time and action can be emtpy it don't know if it can reduce
and if the next STOP/ALERT starts a new ALERT or STOP statement or is
part of the timestamp statement with action. This, because bison has
only one lookahead. Luckily Bison choose to shift which is the right
behaviour in this context. So it means that %expect 4 is okay to use
since we know that bison does the right thing. There are other
choices, if you remove the /* EMPTY */ production from time and from
action the conflict is solved (since bison can use it's one token
lookahead to deduce to shift or reduce). Another option is to do this:

timestamp       : TIMESTAMP PATH operator NUMBER time action ';'

That is, require that the statement ends with a ';'. This solves the
problem. BTW, your timestamp statement is only responsible for two
shift/reduce conflicts, the statement responsible for the other two
are (the problem is the same as described above)

 optionstatement  ->  resource resourcecycle . action 


Despite my introduction above I'm inclined to using "%expect 4"
although it's also tempting to actually fix the problem via changes in
the grammar. What do others think?

-- 
Jan-Henrik Haukeland