Re: are there user defined infix operators?

[Hans Åberg]

> On 10 Nov 2018, at 13:51, Uxio Prego <address@hidden> wrote:
> 
> Alright, but

OK, let's hear!

>> 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.

An implementation detail to be aware of is that if negative numbers are allowed 
as tokens, then 3-2 will parse as 3 followed by -2, not as a subtraction. So 
therefore, it may be better to having only positive numbers, not negative, and 
implement unary operator- and operator+, which is why C++ has them.

So you may not be able to escape having some name overloading.

> 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.

Have a look at the C++ operator precedence table [1]. You might try to squeeze 
in the user defined operators at some point in the middle.

1. https://en.cppreference.com/w/cpp/language/operator_precedence

> 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.

In Haskell, it is a Monad operator, C++ does not have that. :-) The Haskell 
interpreter Hugs has a file Prelude.hs which defines a lot of prelude functions 
in Haskell code.

But Haskell has only 10 precedence levels, which is a bit too little.

> 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.

It is good to think it through before implementing it. Bison makes it easy to 
define a compile time grammar, making it easy to test it out.