Re: are there user defined infix operators?

Alright, but

> On 8 Nov 2018, at 23:37, Hans Åberg <[email protected]> wrote:
> 
>> On 8 Nov 2018, at 22:34, Uxio Prego <[email protected]> wrote:
>> 
>>> [...]
>> 
>> The example and explanation are worth a thousand words,
>> thank you very much. So I use a simple grammar like that, and
>> the stack data structures, and if necessary feed the lexer back
>> with data from the parser once the user requests some infix
>> operators.
> 
> It is only if you want to have a prefix and an infix or postfix operator with the same name, like operator- or operator++ in C++, that there is a need for handshake between the lexer and the parser, and it suffices with a boolean value that tells whether the token last seen is a prefix operator. Initially set to false, the prefix operators set it to true in the parser, and all other expression tokens set it to false. Then, when the lexer sees an operator that can be both a prefix and an infix or postfix, it uses this value to disambiguate. I leave it to you to figure out the cases, it is not that hard, just a bit fiddly. :-)
> 

Yeah, but e.g. I don't plan to define ++ as operator at all, even
though I would want any users wanting it to be able to configure
so.

I guess this would require, either predefining it even with no
actual core semantic; or providing the parser-to-lexer feedback,
and eventually to replace a current vanilla and clean flex lexer
for something else, and/or writing a lot of ugly hack in it.

Now think that the ++ operator has completely different meaning
from a C++ perspective than from a Haskell perspective. Repeat
for the ** operator, which exists in Python or Haskell but not (or
if it does exist, for sure they are not very popular) in languages
like C++ or Java. Some languages provide a // operator, etc. So
predefining is not a good solution I would say.

Anyway this is just thinking about the ultimate possibilities that in
my opinion some abstract extensible spec should try to provide,
or at least foresee, but I don't prioritize to fully implement.


_______________________________________________
[email protected] https://lists.gnu.org/mailman/listinfo/help-bison