Michael Meskes wrote:
> Having a shift/reduce conflict means that you can find a statement that is
> incorrectly parsed.
A shift/reduce conflict means that you can either complete or continue
to parse an expression (if .. then .. else is a famous example). You
will always have this situation when both and expression and its
leading subexpression are valid inputs. There is nothing wrong with
it: any non-trivial grammar will have shift/reduce conflict. Bison is
written to always shift, i. e. attempt to complete valid partial
expressions.
> The system will either do a shift (so the statement is
> parsed via alternative 1) or do a reduce (parsing alternative 2) but what
> you have in mind is certainly only one of these alternatives.
This is what reduce/reduce conflicts are like. They occur when two
entirely different rules can be reduced based on the same sequence of
tokens. Bison aborts and exits when it sees a reduce/reduce conflict,
so you don't have to worry about parts of your grammar not being used.
Tomas Lockhart wrote:
> If it is the kind of shift/reduce conflict reported by yacc/bison
> (rather than a less severe clarification printed in the bison "-v"
> log file) then it means that there is a significant part of your
> grammar which can *never* be reached! The parser will always choose
> one of the two possible paths in the conflict, and will never choose
> the other. Not good if you actually wanted to use the full
> language.
Its sounds more like a mid-rule action in a clause with a shift/reduce
conflict. Inserting an action in the middle of a clause may leave some
of the rules non-functional. There are suggestions on how to fix
that, as well as other conflicts, in the bison manual.
(http://www2.informatik.uni-halle.de/lehre/sprakt/bison.html)
Most conflicts can be fixed by adding intermediate rules. When that
appears difficult, I re-write the input to add artificial tokens
before passing it to the parser.
--Gene
