> because it would be wrong when looking into functions.
Is there some reason you need to treat function parameter lists
as expressions, rather than comma-separated expression lists?
Could you just follow the usual practice of:
a) give ',' and '=' the precedence you desire
b) break your expression non-terminal into two:
comma_expr
: expr ',' expr
| expr
expr
: expr '+' expr'
/* etc., but no comma operator */
| '(' comma_expr ')' /* comma inside parens in a func arg is an
operator */
| func '(' arg_list ')'
arg_list
: expr
| expr ',' arg_list
| %empty
(typed off the top of my head, so probably not error-free.)
This gives you a function parameter list where the parameters
are separated by commas, not comma operators.
On Tue, Dec 17, 2013 at 12:25 AM, Adam Smalin <acidzombi...@gmail.com> wrote:
> I still need help with this. I rewrote it maybe this will be more clear?
>
> I want to allow this
>
> var = var
> var, var = var
> var = var, var
>
> My rules are similar to the below
>
> body:
> recursive-expr //rval = rval is here
> | rval '=' rval ',' rvalLoop
> | rval ',' rvalLoop '=' rval
>
> rvalLoop:
> rval
> | rvalLoop ',' rval
>
> The problem is '=' is higher precedence than ','. When I write "a=b,c" it
> reduce when it sees ',' making a=b an rval and rval ',' rval is invalid so
> my parser fails and "rval '=' rval ',' rvalLoop" is never used. The
> conflict file shows
>
> rval '=' rval . ',' rvalLoop
> Conflict between rule 352 and token ',' resolved as reduce (',' < '=').
>
> How do I say for this rule shift instead of reduce? I don't want to make
> ',' higher than '=' because it would be wrong when looking into functions.
> For example func(a,b=2,c) should have b=2 as an expression and not (a,b) =
> (2,c).
> _______________________________________________
> help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
_______________________________________________
help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
