Re: %prec doesn't seem to work?

[Adam Smalin]

Still wrong. I can do >> and << in the lexer but the problem is... lets
take this for example

List<List<int>>Foo. I need to see >> as two > so it can reduce twice.
However
listVar<listVar2<intVar3>>Foo This needs to do intVar3>>Foo before
comparing with intVar2 to be correct so precedence difference between >>
and > is needed.

I can either lose precedence by treating it as > > or lose the reduce for
templates by having >> which has its own precedence.

I believe %prec is what I want but it DOESN'T do what I want. I don't
understand what it actually does. Why isn't it making the below the same?

| rval '<' '<' rval %prec LSHIFT
| rval LSHIFT' rval

It doesn't seem to change the precedence. It isn't evaluating the variable
before < < like << does. It does ((intVar1<intVar2)<intVar3)< < Foo i
believe. It isnt doing intVar3< < Foo which is what i checked for.



On Thu, Apr 4, 2013 at 9:02 AM, Hans Aberg <address@hidden> wrote:

> On 4 Apr 2013, at 14:48, Akim Demaille <address@hidden> wrote:
>
> > Le 3 avr. 2013 à 20:28, Hans Aberg <address@hidden> a écrit :
> >
> >> On 3 Apr 2013, at 04:52, Adam Smalin <address@hidden> wrote:
> >>
> >>> ... I have no idea how i can fix this without rewriting it all.
> >>
> >> Have you tried getting the lexer to emit two '>' when it sees a ">>",
> say by using an parenthesis-matching integer count?
>
> > I'm not sure what you mean here, if you don't teach the scanner ">>" but
> ">",
> > on ">>" it will return '>' and '>'.  I don't see what you mean with
> > the counter.
>
> One can check the correctness of matching pairs by having an integer,
> starting at 0, increased (resp. decreased) whenever an opening (resp.
> closing) pair is encountered. Matching is fine if one never gets below 0.
>
> So the idea is that the lexer rule '<' increases an integer for this pair,
> and '>' decreases it. Then the lexer rule for ">>" checks if this integer
> is positive; if it is, it sets a flag, and emits a '>', decreasing the
> integer. The lexer first always checks if this flag is set, if it is, it
> resets the flag, decreases the integer, and emits '>'.
>
> There is an additional complication: one needs to know when '<' is not a
> matching pair, in which case the integer should not be increased.
>
> Hans
>
>
>