Re: are there user defined infix operators?

> On 10 Nov 2018, at 13:51, Uxio Prego <[email protected]> wrote:
> 
> Alright, but

OK, let's hear!

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

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.



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