cwcaceres wrote:
But I'm not trying to list. I'm trying to do the add operation. So the
expression "5 6 +4" wouldn't be valid. An example of a valid operation would
be "+5 + -6 - -2" which should have an output of 1. My grammar file
currently outputs the correct result.
I agree with trying to re
maintainers certainly won't understand;
> I prefer to try to remove the conflict.
>
> Evan
>
>
> ___
> help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
>
>
--
View this message in context:
http://www.nabble.com/shift-reduce-conflict-with-unary-tf4303942.html#a12273299
Sent from the Gnu - Bison - Help mailing list archive at Nabble.com.
___
help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Actually, it turns out that the conflict is pretty obvious even without
the debug output. consider this input:
"5 6 +4"
How do you expect this to be scanned? Does it contain 3
summation_expressions ("5", "6", "+4") or 2 ("5", "6+4")? There's an
ambiguity - you haven't defined an expression li
summation_expression go to state 5
unary_expression go to state 6
--
View this message in context:
http://www.nabble.com/shift-reduce-conflict-with-unary-tf4303942.html#a12272535
Sent from the Gnu - Bison - Help mailing list archive at Nabble.com.
___
help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
You don't give enough information. Here's a couple of things to try:
1 - your grammar already has the precedence rules encoded in its
structure. It's obvious, for example, that unary expressions have higher
precedence than summation expressions. You only use the explicit '%prec'
precedence whe
token and how
the parser always just chooses between shifting and reducing. I've also
looked at the output file. However I still don't know how to fix it so that
there'd be no conflict. I'll probably try looking at more examples.
--
View this message in context:
http://www.nabble.c
cwcaceres,
I take it the shift reduce conflict occurs on the input:
NUMBER PLUS NUMBER potentially-other-tokens
which can be reduced to a single summation expression
or shifted because there may be a following UPLUS
Your problem is that you are trying to do too much in too few rules.
Create
unary-expression
( type-id ) cast-expression
unary-expression:
unary-operator cast-expression
unary-operator: one of
* & + - ! ~
--
View this message in context:
http://www.nabble.com/shift-r
cwcaceres wrote:
Hi, I'm having shift/reduce conflict with the unary expression in my grammar
file. I've tried using the %prec modifier but it doesn't seem to work.
It does work, but just not in the way you wanted it to (because you have
put it in the wrong place, but then I would probably no
this message in context:
http://www.nabble.com/shift-reduce-conflict-with-unary-tf4303942.html#a12250917
Sent from the Gnu - Bison - Help mailing list archive at Nabble.com.
___
help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
10 matches
Mail list logo