Re: Proposal for a standard way of defining custom operators in Lua

[Leo Romanoff <romixlev@...>]

----- Ursprüngliche Message -----
> Von: Sean Conner <sean@conman.org>
> An: Leo Romanoff <romixlev@yahoo.com>; Lua mailing list <lua-l@lists.lua.org>
> CC: 
> Gesendet: 20:09 Mittwoch, 24.Juli 2013
> Betreff: Re: Proposal for a standard way of defining custom operators in Lua
> 
> It was thus said that the Great Leo Romanoff once stated:
>> 
>>  I also have observed many times this kind of discissions about
>>  user-defined operators vs keeping it away from the language because they
>>  potentially could lead to a code which is not understood by anyone, since
>>  noone knows the semantics of those operators or their implementations in a
>>  specific context. I've seen those discussions for C (e.g. Linus 
> explaining
>>  why Linux kernel does not use C), for Java, for Scala and many other
>>  languages. 
> 
>   Actually, the Linux kernel does not use C++, but I suspect that was a typo
> on your part.  

Of course :-) I meant C++.

>   One issue I do see is a problem with different code bases selecting the
> same sequence of characters with vastly different semantics, and how they
> interact.  I don't have enough experience with C++ to know how much of an
> issue this is (but then again, you really can't define *new* operators, just
> overload existing ones).  
> 
>   Another thing left unspecified---say I define an operator "$"---can 
> I only
> used existing types on either side?  Or can I specify a particlar way to
> parse the text surrounding the operator?  For instance, In Lua, the 
> "+"
> operator is only defined for numbers, and can throw an error if it sees:
> 
>     "one" + "two"
> 
> (unless one has redefined the metatable for strings).  But for my
> hypothetical "$" operator, I might want it to be a unary operator that
> affects the parsing after it's encountered to mean "number as 
> hexidecimal
> value", so the following would be equivilent:
> 
>     y = x + 0xABCD
>     y = x + $abcd
> 
> (why yes, I did a ton of assembly programming in the 80s).  But getting back
> to the original problem, someone else could write a "$" operator, also 
> as a
> unary operator, that means "return the value of the environment variabled
> named", such that:
> 
>     x = $HOME .. "/source/lua/test.lua"
> 
> So, how would you parse:
> 
>     x = $BABE
> 
>   Is it a hexidecimal number (so x would be 47806) or the value of an
> environment variable BABE (which means x is either nil, or a string)?  I
> mean, assuming I included *both* definitions of "$".  And if that is 
> even
> possible, and how to handle such conflicts.  I would hate to have a large
> amount of code using my definition of "$" only to need a module that 
> has its
> own definition of "$".

I see your concern. But typically operators are overloaded or defined for new user-defined types (i.e. userdata or tables). 
The goal is not to define a new strange semantics for builtin datatypes and operators, though it could be done.
Usually it is a very bad idea to do so due to the reasons that you describe and many others.

It is also not adviced to introduce conflicting or counter-intuitive definitions, e.e. defining __plus with a semantics of minus, etc.

But one thing to mention here is also the following:
- Let's forget about operators for a moment. Let's speak about APIs. Imagine an API that defines a method X. Now everyone can implement her own version of method X (an in languages with function overloading or in OOP languages each such implemenation may even have the same name). And there is no way to guarantee that this implementation is not contradicting other implementations or expected semantics of this API. This is a responsibility of a developer to implement it in a meaningful and compliant way. 

My point is that IMHO the problem of conflicts and sematics is not specific to operator overloading or definition of new operators. It already exists even for simple functions and APIs.

>>  I totally agree that when this feature gets out of control and everyone
>>   starts implementing his own cryptic operators, then it may lead to a
>>   disaster. But I also think that any feature of the language, when it is
>>   misused, could result in  a lot of problems. And I'm not sure that
>>   operaor overloading specifically is very special in this regard. After
>>   all, many people seem to like Moonscript & the like due to a new 
> syntax
>>   and operators that it introduces, which may be an indication that current
>>   syntax of Lua is a bit too verbose (or too low-level, if you wish) for
>>   some people. Also many people programming in Java (which is also
>>   intentionally a bit minimalistic when it comes to syntax, because Sun
>>   wanted Java to be a "C for JVM") are now trying to escape to 
> more
>>   expressive languages running on JVM, e.g. Scala, Groovy, Kotlin and many,
>>   many others. Of course, all that happens due to lack of expressiveness or
>>   too much verbosity in the original language, and not due to user-defined
>>   operators only.
> 
>   I don't mind verbosity---I think minimalism is overrated (APL anyone?  How
> about Forth?).  I suspect minimalism comes from programmers hating to type
> rather than any notions of purity (one friend knew a programmer who
> literally would cut-n-paste, even individual letters, because he disliked
> typing).


May be. But looking at the prevalence of languages which actively use brackets over languages using begin/end I have my doubts ;-)
I think expresiveness of the language and ability to provide a concise notation is playing a big role here as well ...
E.g. (sorry for a bit stupid example)

dst <- msg1 <- msg2 <-msg3 vs send(send(send(dst, msg1), msg2), msg3)

-Leo