[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Precedence and "overloaded" operators
From: |
Joel E. Denny |
Subject: |
Re: Precedence and "overloaded" operators |
Date: |
Sun, 3 Jan 2010 12:38:36 -0500 (EST) |
User-agent: |
Alpine 1.00 (DEB 882 2007-12-20) |
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.