Re: shift/reduce problem

Hans Aberg <>
Fri, 03 Dec 2010 20:19:28 +0100

          From comp.compilers

Related articles
shift/reduce problem (JohnSmith) (2010-12-02)
Re: shift/reduce problem (Hans Aberg) (2010-12-03)
Re: shift/reduce problem (JohnSmith) (2010-12-03)
Re: shift/reduce problem (Hans Aberg) (2010-12-03)
Re: shift/reduce problem (Gene) (2010-12-03)
Re: shift/reduce problem (Chariton Karamitas) (2010-12-05)
Re: shift/reduce problem (Seima) (2010-12-30)
Re: shift/reduce problem (Kaz Kylheku) (2011-10-20)
| List of all articles for this month |

From: Hans Aberg <>
Newsgroups: comp.compilers
Date: Fri, 03 Dec 2010 20:19:28 +0100
Organization: A noiseless patient Spider
References: 10-12-004 10-12-006 10-12-007
Keywords: parse
Posted-Date: 03 Dec 2010 22:50:20 EST

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 .
> 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
> (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.

Post a followup to this message

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