Re: shift/reduce problem

On 2010/12/03 14:49, JohnSmith wrote:
>> Use the flags
>> bison --verbose --report=all
>> to get the .output file. Look for the state, and in it, the conflicting
>> rules, and in those, the two tokens immediately before and after the
>> parsing position ".". The token precedences %left, ..., set preferences
>> between those pairs.
...
> State 483 conflicts: 1 shift/reduce
>
> state 483
>
> 165 input_declaration0: K_input opt_range list_of_variables .
> [K_COMMA, K_RIGHTPAREN]
> 181 list_of_variables: list_of_variables . K_COMMA name_of_variable
>
> K_COMMA shift, and go to state 210
>
> K_COMMA [reduce using rule 165 (input_declaration0)]
> $default reduce using rule 165 (input_declaration0)
>
> I set this preference
> %left K_IDENTIFIER K_COMMA K_RIGHTPAREN
> (tried %left K_COMMA K_RIGHTPAREN also)
>
> But still got shift/reduce conflict, and syntax error when parsing the
> file.


You do not have a token immediately before the "." in the one rules. So
token precedences do not work on this grammar. So,


> [Hmmn. This is an LR(2) grammar. There must be a way to rewrite it
> as LR(1) but I have to say I don't immediately see what it
> is. -John]


as John points out, in order to remove them, the grammar must be
rewritten. Alternatively, it may just happen that the choice Bison is
making, shift before reduce, is right, and you can ignore it, or take it
away using %expect. If that does not work, you may look up the GLR
parser, which splits ambiguities, giving the possibility of making the
choice later. When rewriting the grammar, it may be better to put some
stuff into the rule actions, that is, parse a more general language, and
cut issue errors in the rules.

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