Re: %prec doesn't seem to work?

[Adam Smalin]

Report what? I was just saying I didn't notice any errors/warnings (I don't
remember if I tried to compile all of it) and that I am positive I compiled
it right.

FYI I AM using a glr parser. My first line is %glr-parser

Is the code at the bottom the recommended way? I wrote out %left and %right
which seemed to resolve all of that.
My bison file is roughly 1200 so I rather not rewrite it if I don't need to


On Sun, Mar 31, 2013 at 4:54 AM, Akim Demaille <address@hidden> wrote:

>
> Le 30 mars 2013 à 17:48, Adam Smalin <address@hidden> a écrit :
>
> > Here is a sample of my y file.
> >
> >    | rval '<' rval
> >    | rval '<' '<' rval
> >    | rval '>' rval
> >    | rval '>' '>' rval
> >
> >    | rval LSHIFT rval
> >    | rval RSHIFT rval
> >
> > I'd like to allow < < and > > to work like << and >>. I thought they
> would
> > be difficult but found "Context-Dependent Precedence"
> >
> http://www.gnu.org/software/bison/manual/html_node/Contextual-Precedence.html
> >
> > However it doesnt seem to work. Writing
> >    | rval '<' '<' rval %prec LSHIFT
> >
> > seems to do nothing.
>
> You face a shift/reduce conflict (well, several), and these are resolved
> by check the _one_ next token (this is LALR(1): 1 means a single lookahead
> token).  In your case, you'd like Bison to check the _two_ next tokens,
> < and <, and to treat that as <<.  It cannot work.
>
> > I tried putting it here where * = "%prec LSHIFT"
> > except i only had one at a time
> >
> >    | * rval * '<' * '<' * rval  *
>
> %prec qualifies the whole rule, it does not matter where you write
> it.
>
> > Every slot didnt seem to work. I didnt notice any warnings except when I
> > had more than one %prec LSHIFT in a rule.
>
> Thanks for reporting this.
>
> > How do I get bison to treat > > and << as >> and <<. Note: I can't make
> > shift >\s*> in the lexer because that would interfere with other things
>
> Well, this is the most natural treatment though, for a deterministic
> parser.  Another approach would be to move to a GLR parser, which is
> designed to work around such local nondeterminism (it will "wait" to
> see enough tokens to decide which rule is right).  Finally, you can
> probably eliminate these conflicts by reworking your grammar to be
> non ambiguous _without_ % directive.  For instance, + and * are to
> be written
>
> exp: sum
>
> sum: sum + prod | prod
> prod: prod * fact | fact
> fact: NUM
>
> etc.