[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Proposal for a standard way of defining custom operators in Lua
- From: Leo Romanoff <romixlev@...>
- Date: Wed, 24 Jul 2013 08:58:24 -0700 (PDT)
----- Ursprüngliche Message -----
> Von: Duncan Cross <firstname.lastname@example.org>
> An: Leo Romanoff <email@example.com>; Lua mailing list <firstname.lastname@example.org>
> Gesendet: 15:13 Mittwoch, 24.Juli 2013
> Betreff: Re: Proposal for a standard way of defining custom operators in Lua
> On Wed, Jul 24, 2013 at 10:53 AM, Leo Romanoff <email@example.com> wrote:
>> Of course, using Metalua or some macro systems for Lua one could probably
> achieve the goal, but it sounds like an overkill for me.
>> Therefore I was thinking about the following idea:
>> - Introduce in Lua a standard mechanism to define a new operator.
> I have the opposite view: using a third-party macro system is not the
> "overkill" solution, introducing a feature in the language is. I just
> don't see custom operators as such a massively useful thing across
> many real usage domains to justify the added core complexity.
I'm not sure where the added core complexity comes from. Currently, Lua already does dispatch of special methods via metatables anyway for userdata and tables. This is used by many Lua libraries (some overload indexing, some overload plus or minus, etc).
The only new things that I propose are:
- ability to extend the set of lexemes recognized by the lexer
- ability to extend the set of special methods in metatables (you get a new special method name for each new operator)
And these two things are optional: if you don't want to use them, don't use them. And then there is no additional overhead at all.
But the metatable related dispatch is not changed at all. It remains as it is now and it is performed today anyway.
> There is also the fact that Lua's expressions and statements are
> strictly separated. You mention a "__send" operator - let's say
> operator is "<~", you would not be able to do "send_to_me
> <~ value;"
> as a statement. You would have to do something like "local _ =
> send_to_me <~ value;", assigning to a dummy variable to ignore the
> final value of the operation.
Yes, it is an interesting catch. It would be really nice to have just an expresion without a fake assignment.
But I'd say this problem of "expressions vs statements" is an orthogonal one and has little to do with user-defined operators specifically, as it is useful on its own.