Re: __colon

[Philipp Janda <siffiejoe@...>]

Am 01.05.2014 23:07 schröbte Eduardo Ochs:
> I am afraid that this post may sound a bit rude - so apologies in
> advance...
>
> The semantics of "a:b(c)" is already defined, and in a way that is not
> going to change; and at present an "a:b" without the "(...)"
> afterwards just raises a syntax error.
>
> People are now discussing, for the n-th time, a FIXED semantics for
> "a:b" without the "(...)" - as if there could be an agreement!...

It's only three people who have to agree on a proposal (at most, I 
actually don't know how disagreements are resolved in the PUC-Rio Lua 
team). (And as Thomas has said repeatedly his recent activity is not 
meant as a change proposal for Lua ...)

> Wouldn't it be much more Lua-ish to just create a new metamethod for
> that? Here's how it would work. The current behavior of "a:b(c)" would
> not be changed at all, and in all situations where "a:b" currently
> raises a syntax error - including "(a:b)(c)" - Lua would instead
> generate code that would look for a metamethod "__colon" in the
> metatable of a; when that metamethod is found, the result of "a:b"
> would be this,
>
>    getmetatable(a).__colon("b")
>
> and when a doesn't have a metatable, or when a has a metatable but it
> doesn't have a "__colon" field, Lua would just raise an error: "Colon
> behavior not defined for <a>" - or it would look for a default action
> in a global variable whose name we would have to decide - "__colon",
> maybe?

IMHO, the `__colon` field per metatable would be confusing, because an 
object from one module would behave differently than an object from the 
next module, and you would need to keep track of where an object came 
from. So far the semantics of metamethods are more or less fixed, and 
the backends/implementations differ. This would be the other way around. 
I don't think it would be beneficial if *all* colon proposals so far 
actually ended up in Lua code ...
On the other hand, the global `__colon` setting would just cause 
conflicts like all other shared global settings, e.g. metatables for 
`_G`, metatables for non-userdata/-table types, etc.
So, my opinion is: As long as it isn't clear how it should be done, it 
shouldn't be done at all! It's not an essential feature after all.
Maybe things will become clearer when Thomas has tested his patch in 
some real-world situations.

> Btw, here is a related idea (that got no responses):
>    "Re: Multiple indexing (was: 'in' keyword today)"
>    http://lua-users.org/lists/lua-l/2014-04/msg00544.html

I not sure the extra metamethods are necessary (and I find them sort of 
ugly) as long as `__index` always returns exactly one value (the extra 
arguments to `__index` probably wouldn't hurt even if you didn't expect 
them). This would allow matrix-like indexing, but not getting multiple 
values from a single table in one go (as was the intended use case in 
the thread you linked). Making `__index` return a variable number of 
return values is more of a breaking change (and for plain tables I 
_still_ would only return one value by default), but IMHO better than 
two metamethods that basically do the same thing. For now I will go 
with: As long as it isn't clear ..., and implement multi-indexing as 
functions[1].

> and here's a link to some recent messages on ":" (april 2014 only):
>    "Ideas about colon operator syntax (and a patch in the work)"
>    http://lua-users.org/lists/lua-l/2014-04/threads.html#01318
>
> Cheers,
>    Eduardo Ochs


Philipp


  [1]: https://github.com/siffiejoe/lua-multikey