help-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: %prec doesn't seem to work?


From: Akim Demaille
Subject: Re: %prec doesn't seem to work?
Date: Sun, 31 Mar 2013 10:54:38 +0200

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]