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 <a...@lrde.epita.fr> wrote: > > Le 30 mars 2013 à 17:48, Adam Smalin <acidzombi...@gmail.com> 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. _______________________________________________ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison