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

[Sean Conner <sean@...>]

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.  

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

  -spc