Re: how to solve this reduce/reduce conflict?

[Lukas Arsalan]

Hi,

At 2022-09-22T07:08:55CEST Akim Demaille <akim@lrde.epita.fr> 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&bison?

> 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