Re: are there user defined infix operators?

[Uxio Prego]

Alright, but

> On 8 Nov 2018, at 23:37, Hans Åberg <address@hidden> wrote:
> 
>> On 8 Nov 2018, at 22:34, Uxio Prego <address@hidden> 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.