Shift/reduce conflict with C-like grammar under Bison -


i've been working on c-like grammar personal amusement. however, i've been running shift/reduce conflicts, , i'm quite sure resolved.

right expressions this, in simplified form, stripped of actions:

%left '+' '-'  %% expr  : number  | identifier  | expr '+' expr  | expr '-' expr  /* other operators '*', '/', etc. */  | expr '(' expr ')' /* function call */ %% 

however, results in shift/reduce conflicts: parser unsure how treat parentheses. -v tells me, unclear whether expression expr '+' expr '(' should reduce expr '+' expr expr or shift parenthesis.

obviously, want parenthesis shifted. foo % bar(4) shouldn't end being (foo % bar)(4). however, i've had no success using %prec directive mean. adding %left funcall , %prec funcall after rule yields no change.

i know default path bison's lalr parsers go when encountering shift/reduce shift, , use %expect fix work around problem. however, 1 conflict generated each expression, , ever need change list, i'll need change %expect declaration, looks rather ugly solution me. besides, i'm sure 1 of wise kids have solution problem.

my goal have rule similar 1 above, bison know whenever encounters '(' function call rule, has shift parenthesis, without possible shift/reduce conflict. record, use of %prec directive following, if i'm doing wrong can correct me. have shift/reduce conflict.

%left '+' '-' %left funcall  %%  expr     : number     | identifier     | expr '+' expr     | expr '-' expr     /* other operators '*', '/', etc. */     | expr '(' expr ')' %prec funcall /* function call */  %% 

you need add %left '(' precedence rules (or %nonassoc '(' might better).

the way precedence works resolve shift/reduce conflicts in yacc/bison compares precedence of rule reduced precedence of token shifted. in example, conflict between reducing expr: expr '+' expr , shifting '(', resolve it, need precedence on '(' (and want higher rule, comes '+')

the %prec directive sets precedence of rule, overriding default precedence comes first token on rhs. doesn't affect precedence of tokens appear in rule in way.


Comments

Popular posts from this blog

unicode - Are email addresses allowed to contain non-alphanumeric characters? -

C#: Application without a window or taskbar item (background app) that can still use Console.WriteLine() -

c++ - Convert big endian to little endian when reading from a binary file -