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

[Leo Romanoff <romixlev@...>]

----- Ursprüngliche Message -----

> Von: Lorenzo Donati <lorenzodonatibz@tiscali.it>
> An: lua-l@lists.lua.org
> CC: 
> Gesendet: 15:02 Donnerstag, 25.Juli 2013
> Betreff: Re: Proposal for a standard way of defining custom operators in Lua
> 
> On 25/07/2013 14.03, steve donovan wrote:
>>  On Thu, Jul 25, 2013 at 1:51 PM, Lorenzo Donati
>>  <lorenzodonatibz@tiscali.it 
> <mailto:lorenzodonatibz@tiscali.it>> wrote:
>> 
>> 
>>      Yes, choosing good names is more an art than a science, but choosing
>>      good symbols sometimes is akin to witchcraft!
>> 
>> 
>>  Oh yes!  Where overloading does make sense is implementing generalized
>>  arithemetic operations (e.g. classic 'operations on a field' + - * 
> / ^
>>  with corresponding 'zero' and 'one' meanings) and there we 
> have all the
>>  operators we need.
> 
> Yes, really what I also had in mind.
> 
>> 
>>  A (great) exception is LPeg which uses operators to create a powerful
>>  notation.
>> 
> 
> Although I know LPeg only superficially (yet - I hope ;-), still its 
> notation mimicks strongly those already established in the CS field (if 
> I'm not mistaken), so this wouldn't contradict my point: operator 
> overloading is great when you already know an operational notation and 
> the underlying semantics (fields operation, EBNF, etc.)

In principle, I agree with you, guys. But I do not quite follow why you think that allowing definition of custom operators would result in introducing a huge set of strange operators, whose semantics is not known to anyone besides its creators. Why so black and white, why looking only at the extremes? Either no custom operators at all or use them to the extent where nobody can follow...

Many of you say in the same message that custom operators are evil and dangerous, but then also say that yes, for bit operations it would be nice, and LPEG notation is also not that bad after all, because it follows a certain well-known notation, etc. Basically you say that operators and DSLs are nice, if they are defined in a meaningful way and follow a well-known notation. 

But this is exactly what I'd like to achieve as well. My proposal is not to introduce a "wild West" when it comes to custom operators and overloading, but to provide a basic (I'd even say minimal) mechanism to define them. Obviously, one should take care and introduce meaningful, well-known notation whenever possible, instead of introducing new unknown notations with strange meanings.

And if people are too afraid of introducing really strange free form symbolic forms for operators, then may be a weaker approach can be taken: 
- Let Lua recorgnize a "stable" set of well-known operators which we know from existing programming languages. E.g. it could recognize (but does not need to understand their semantics. It just needs to dispatch them via metatables and let those methods handle the semantics) most/all of C, Java , Python, Ruby operators, etc. Most of the operators are the same anyway among those languages. There are only few symbolic names that are very unique for a specific language.  
With this approach, we limit the damage because no free-form operators can be defined. But we have a richer set of operators than we currently have in Lua. It can be useful for expressiveness of Lua as such and it can make a process of mapping existing code from other languages to Lua also a bit easier.

Regarding "minimal" mechanism:
Some people mentioned that LPeg or Metalua could/should be used. I agree that this is the case, but I think it is an overkill for the task. Let me explain:
We only want to add a few new lexemes to the language dynamically and essentially it is the lexer that needs to be affected. And this is how I envisioned a possible implementation. IMHO, this is a minimal required change.

Assuming that one would use LPeg or Metalua instead would mean that at design time one defines a new parser and at runtime this parser needs to parse the whole source file containing new operators in a preprocessing step just to convert those few new lexems into a pure Lua code, which needs to be feed into into Lua interpreter or JIT and parsed again. IMHO, this is quite some overhead for such a simple task, but your mileage may vary. It is like writing a new compiler just to be able to parse one new token, instead of introducing a small change in the existing parser/lexer.

-Leo

>>  Even in C++, the standard library makes very sparing use of operator
>>  overloading, + for strings, << & >> for stream 
> reading/writing, [] for maps.
>> 
>>  I agree with Lorenzo that otherwise an impressive string of symbols is
>>  an attempt to make 'code' (source) look like 'code' (a 
> secret cipher).
>>  Not a good fit for a DSL intended for non-professional programmers!
>> 
> 
> 
> -- 
> ()  ascii ribbon campaign - against html e-mail
> /\  www.asciiribbon.org   - against proprietary attachments
>