Re: Precedence and "overloaded" operators

[Joel E. Denny]

On Sat, 2 Jan 2010, "Víctor M. González" wrote:

> Given the following operators:
> 
> %left '+' '-'
> /*...*/
> %right SOME_UNARY_OPERATOR
> %left STRING_CONCATENATION
> 
> And the following rules:
> 
> integer:
>    SOME_UNARY_OPERATOR string ;
> 
> string:
>    STRING |
>    string '+' string %prec STRING_CONCATENATION ;
> 
> Bison can't figure out the correct precedence for "string '+' string", and no
> matter what I do, the report insists that ('+' < STRING_CONCATENATION),

That is the precedence you declared, but it shouldn't be relevant for your 
example input, which has only one '+'....

> which
> is a problem because it understands the string (SOME_UNARY_OPERATOR
> "str"+"ing") as ((SOME_UNARY_OPERATOR "str")+"ing"), which is a syntax error.

You appear to have omitted part of you grammar, so my analysis is a guess.  
Specifically, what's the context of integer?  In order for the parse you 
describe to be correct, it looks like '+' would have to be able to appear 
after integer in your grammar.  Can it?  If not, then it appears that 
either you've run into an LALR shortcoming or the parse should be 
(SOME_UNARY_OPERATOR (string '+' string)) as you seem to expect.

> However, if I leave out the first '+' (the one just above the /*...*/), it
> finally works as it should.
> I can also get around it if I change the troublesome rule to
> STRING '+' string %prec STRING_CONCATENATION
> That forces Bison to delay the reduction of the rule, but at the cost of stack
> space.

If '+' can appear after integer, then all of this looks like correct 
behavior to me.