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

[Leo Romanoff <romixlev@...>]

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

> Von: Coda Highland <chighland@gmail.com>
> An: Leo Romanoff <romixlev@yahoo.com>; Lua mailing list <lua-l@lists.lua.org>
> CC: 
> Gesendet: 13:54 Mittwoch, 24.Juli 2013
> Betreff: Re: Proposal for a standard way of defining custom operators in Lua
[snip]
>>  Benefits of this approach for defining new custom operators:
>>  - It is very generic and powerful
>>  - It makes it easier to define DSLs (domain-specific languages) and custom 
> syntax using Lua
>>  - Follows Lua ides of using metatables for dispatching operators to their 
> implementations
>>  - Allows for definition of ANY symbolic operators (as long as they 
> represent a character sequence without spaces in between)
>>  - Introduces rather small changes to the lexer (At least I think that 
> required changes would be rather small)
>>  - Does not require any changes in the Lua VM
>>  - It does not change the semantics of existing Lua programs (unless someone 
> wishes to explicitly redefine standard operators)
>> 
>>  What do you think about this proposal?
>>  - Does it sound technically feasible with a relatively low implementation 
> effort?
>>  - Would it be useful as a built-in feature of Lua?
>>  - Have you already experienced situations/projects where you wished you 
> would like to have such a feature?
>>  - Are there any strong arguments against having this feature as a built-in 
> feature in Lua?
>> 
>>  Looking forward to your feedback!
>> 
>>  Thanks,
>>     Leo
>> 
>> 
> 
> Now, my secondary concern with this proposal is runtime performance.
> Usually, when you're overloading operators, you want to be able to
> dispatch according to the type of the operators, but your proposal
> avoids modifying the VM, which means that the dispatch is determined
> at parse-time, which is going to kill runtime performance -- that's
> not operator overloading, that's operator OVERRIDING. Lua's
> dynamically-typed nature is going to keep you from being able to
> reliably reason about the types of variables. If you overload, say,
> operator+ to allow addition operations on your user-defined type,
> you've just slowed down mathematical addition for the entire source
> file.

Is it really the case? In Lua it is possible to define operator + by means of a metatable even today, without my extension.
Do you say that it slows done everything already now? If not, why would my proposal make things slower? I just have the same thing in mind. The only difference is that I want to allow user-defined lexemes for the new operators.

Another remark about runtime performance is:
I think LuaJIT is pretty good in optimiting metatable and table lookups. After all, it has to do it already now for a set of predefined special methods in metatables.
And Lua VM anyway does it for a set of predefined special methods in a metatable. 
Therefore, I don't see how my extension would change performance. It will be the same lookup, but the set of keys (i.e. special method names) is now extendible.

> Yes, you could theoretically restrict the scope of the operators to
> only apply to a certain set of functions, but now you're starting to
> lose the convenience and the generic-programming nature of operator
> overloading.

I like these arguments more, because they are more technical ;-)

Well, I agree with you that dispatching based on type of all arguments would be nice.
But if understand current way of how Lua handles operators via metatables and special methods (e.g. operator + or -), what you describe is not how Lua works today. Today dispatching is done based on the metatable lookup of the first argument, right?  Therefore my proposal followed exactly the same approach. Should Lua ever introduce function/operator overloading based on types of arguments, my proposed feature could make use of it.

The goal of the proposal was to introduce mimimal changes and follow the current practices.

> Honestly, the better solution is to go ahead and modify the VM core so
> that you can dispatch the operators according to the metatable, and
> actually get your dynamic dispatch.

Yes, modifying the VM would be a more powerful way to implement it. But it requires more modifications, it implements more than one feature IMHO (it extends not only the syntax, but also Lua's operator/function overloading semantics) and these things are orthogonal, because dispatching based on types of all arguments is an interesting feature on its own, even without any user-defined operators. For me, doing one thing at a time is a safer approach. 

Modifying a VM could be a next step, if enough people say they want to dispatch the operator based on types of its arguments. But somehow I doubt that it is likely to happen in Lua soon, bacause it is dynamic language without strict typing ...


-Leo