Re: how to solve this reduce/reduce conflict?
On 2022-09-22T15:54:31UTC Hans Åberg wrote: > Context switches are best avoided unless absolutely necessary, in my > experience. > So if one designs ones own language, it might be good to try to avoid them > by a change in the grammar. > OK... I know that there are no signed numbers usually... But I wanted to try to change that... So for _me_ in "-2" the minus is a sign... And in "- 2" the minus is a unary inversion operator... And in "1-2" the minus is a subtraction operator (or an abbreviation for "1+-2" respectively (where the minus is a sign again))... This can all be done quite elegantly with this context trick in the ll-file... > It might be confusing with -2^4 meaning (-2)^4, because in 1 - 2^4, it should > be 1 - (2^4), > and 1 -2^4 would be an error if two number cannot follow each other. > "1 -2^4" is no error in my program... it results in "-15". It even says, that "- 2^4" is "-16", while "-2^4" is "16". 拾 Do u think there will be any unwanted side effects? -arne
Re: how to solve this reduce/reduce conflict?
On 2022-09-22T07:57:45UTC Hans Åberg wrote:
> On 22 Sep 2022, at 08:30, Lukas Arsalan wrote:
>> [1] -1 --> "num"
>> [2] 1-2 --> "num" "-" "num"
>> [3] (-1^-2) --> "(" "num" "^" "num" ")"
>> [4] 1--2 --> "num" "-" "num"
>> [5] 1---3 --> "num" "-" "-" "num"
>> [6] 1-2^3 --> "num" "-" "num" "^" "num"
>> I do not think that it is possible, to do that with regular expressions...
>>
> I think it is not possible, so therefore one expects -2⁴ to be parsed as
> -(2⁴).
>
I found that `%s nosinum` for the ll-file...
Now I can do things like this:
"+" BEGIN(INITIAL); return yy::parser::make_ADD(loc);
"(" BEGIN(INITIAL); return yy::parser::make_BROP(loc);
")" BEGIN(nosinum); return yy::parser::make_BRCL(loc);
{bint} BEGIN(nosinum); return make_INT(yytext,loc);
{float} BEGIN(nosinum); return make_FLOAT(yytext,loc);
[+-]?{bint} BEGIN(nosinum); return make_INT(yytext,loc);
[+-]?{float} BEGIN(nosinum); return make_FLOAT(yytext,loc);
and i removed the SNUM token...
now it seems to work just right.. 拾
it even handles the whitespaces to my liking...
but i do not know what kind of formal language that is now...
-arne
Re: how to solve this reduce/reduce conflict?
Hi,
At 2022-09-22T07:08:55CEST Akim Demaille wrote:
> This snippet is clearly ambiguous, since it allows two different parses of
> -1, which -Wcex nicely showed.
>
yes. right.
> If I were you, I would handle this in the scanner. IOW, the scanner should
> be extended to support signed literals, and > process that initial `-`.
>
uhm... is that possible?
e. g.:
[1] -1 --> "num"
[2] 1-2 --> "num" "-" "num"
[3] (-1^-2) --> "(" "num" "^" "num" ")"
[4] 1--2 --> "num" "-" "num"
[5] 1---3 --> "num" "-" "-" "num"
[6] 1-2^3 --> "num" "-" "num" "^" "num"
I do not think that it is possible, to do that with regular expressions...
flex would have to remember the previous token, that it found...
A "-" after no token and after the tokens "-", "+", "^", "(" is a sign, if
followed by a digit...
else the "-" is an operator...
That sound like bison's job... right?
Or can it be done in flex?
Or can bison reject a token (e. g. a "num" after a "num" in the case of "1-2")
and make flex using a different rule?
and i m still not sure, what to do with whitespaces (e.g. "- 3")...
currently i just ignore them...
What kind of grammars is bison capable of parsing?
I mean: Is my grammar too complicated for flex?
> So the grammar would no longer include `exp: "num"`.
>
u mean`exp: "-" "num"`?
> Your actions look quite badly typed. And `std::endl` should seldom be used,
> `'\n'` is enough.
>
I am concerned about
1. parser errors
2. memory leaks
3. efficiency of debug code... :-)
Thx.
-arne
how to solve this reduce/reduce conflict?
Usually -2^2 is considered to be -4, because: the minus is interpreted as a
unary operator with lower precedence, than ^ (power)... E.g.:
http://www.isthe.com/chongo/tech/comp/calc/
_but_:
I would like to have a parser,
[1] that binds the sign of a number stronger than a ^ (power), and
[2] that binds the unary inversion-operator of an expression weaker than a ^
(power).
My parse works, but the bison manual says, that i shalt fix the conflict,
because it is somehow worrisome.
https://www.gnu.org/software/bison/manual/html_node/Reduce_002fReduce.html
example:
[1] -2^2=(-2)^2=4
[2] a=2 ; -a^2=-(a^2)=-(2^2)=-4
In this yy-file is a reduce/reduce conflict:
%left "+" "-";
%right "^";
exp:
"-" "num" { $$ = -*new Float($2); std::cout << "NUMinv" << $$ <<
std::endl; }
| "num" { $$ = new Float($1); std::cout << "num" << $$ <<
std::endl; }
| "+" exp { $$ = $2; std::cout << "noninv" << $$ << std::endl; }
| "-" exp { $$ = -*$2; std::cout << "inv" << $$ << std::endl; }
| exp "+" exp { $$ = *$1 + $3; std::cout << "add" << $$ << std::endl;
}
| exp "-" exp { $$ = *$1 - $3; std::cout << "sub" << $$ << std::endl;
}
| exp "^" exp { $$ = *$1 ^ $3; std::cout << "pow" << $$ << std::endl;
};
bison -Wcounterexamples says:
Example: "-" "num" •
First reduce derivation
exp
↳ 4: "-" "num" •
Second reduce derivation
exp
↳ 7: "-" exp
↳ 5: "num" •
How can i solve that without a preprocessor, that wraps negative numbers (e.
g.: "-4*(-2+-3)" --> "(-4)*((-2)+(-3))") with brackets?
-Arne
