help-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: shift/reduce conflict with unary


From: cwcaceres
Subject: Re: shift/reduce conflict with unary
Date: Wed, 22 Aug 2007 04:16:42 -0700 (PDT)


Evan Lavelle-2 wrote:
> 
> 1 - your grammar already has the precedence rules encoded in its 
> structure. It's obvious, for example, that unary expressions have higher 
> precedence than summation expressions. You only use the explicit '%prec' 
> precedence when  there *isn't* an obvious precedence in your grammar; 
> you shouldn't have both. Take out the %prec/%lefts, see what happens. 
> The portion of grammar that you give looks Ok without these extras, but 
> something else might give a conflict.
> 

I started out without %prec and there was 1 shift/reduce conflict.

%token NUMBER 
%token PLUS MINUS OR XOR
%token BIT_NOT NOT 
%%
expression_list
                : /* empty */
                | expression_list summation_expression
                ;
summation_expression
                : unary_expression
                | summation_expression PLUS unary_expression
                | summation_expression OR unary_expression
                ;
unary_expression
                : NUMBER
                | PLUS NUMBER 
                | NOT NUMBER
                ;

conflict part in output file:

state 6

    2 expression_list: expression_list summation_expression .
    4 summation_expression: summation_expression . PLUS unary_expression
    5                     | summation_expression . OR unary_expression

    PLUS  shift, and go to state 10
    OR    shift, and go to state 11

    PLUS      [reduce using rule 2 (expression_list)]
    $default  reduce using rule 2 (expression_list)

--
I've found that this will process "+1" and "1+1" even with the conflict. Is
it okay if I disregard the conflict if the grammar works anyway?


Evan Lavelle-2 wrote:
> 
> 2 - Take out the "| PLUS NUMBER" rule. Do you still have a problem?
> 

If I take that out, there is no conflict but the output file shows this
(below) which I think makes it impossibe to process a value like "+1"
although it will process "1+1"

state 0
    0 $accept: . expression_list $end
    $default  reduce using rule 1 (expression_list)
    expression_list  go to state 1

state 1
    0 $accept: expression_list . $end
    2 expression_list: expression_list . summation_expression

    $end    shift, and go to state 2
    NUMBER  shift, and go to state 3
    NOT     shift, and go to state 4

    summation_expression  go to state 5
    unary_expression      go to state 6




-- 
View this message in context: 
http://www.nabble.com/shift-reduce-conflict-with-unary-tf4303942.html#a12272535
Sent from the Gnu - Bison - Help mailing list archive at Nabble.com.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]