Re: how to solve this reduce/reduce conflict?
This is horrid, and not how math works. Spaces necessarily mean nothing, and imbuing them with meaning is nonsense. Please reconsider your grammar. > On Sep 22, 2022, at 8:28 PM, Lukas Arsalan wrote: > > 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-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 22 Sep 2022, at 21:02, Lukas Arsalan wrote: > > 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... I think the C/C++ interpretation with a unary operator and no signed integers is the best one for arithmetic expressions. Having a sign as a prt of the numer may be suitable in other contexts. >> 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? In the minds of those interpreting it. :-)
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?
> On 22 Sep 2022, at 16:52, Lukas Arsalan wrote:
>
> 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...
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.
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.
Re: how to solve this reduce/reduce conflict?
> On 22 Sep 2022, at 08:30, Lukas Arsalan wrote:
>
> 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...
I think it is not possible, so therefore one expects -2⁴ to be parsed as -(2⁴).
