Re: __method metamethod

[Jay Carlson <nop@...>]

On Jul 28, 2013, at 9:50 PM, Coda Highland wrote:

> On Sun, Jul 28, 2013 at 4:42 PM, Jay Carlson <nop@nop.com> wrote:
>> On Jul 27, 2013, at 2:47 PM, Mark Hamburg wrote:
>> 
>>> I used to want the colon operator raised to first-class status where it could then have a metamethod, but I never found a formulation that really seemed useful. (Someone can go find my old postings on the topic and point out how much I forget...)
>> 
>> I have a very bad feeling about creating *half* an extra namespace. We might as well make it an lvalue too: __setmethod.
> 
> I still think that __index is sufficient here; I have a very bad
> feeling about having a.b and a:b reference different concepts.

Oh, sure. The next question is how a:b is related to a["b"], and I think the answers get worse and worse until you arrive at a two-namespace Python-object-like table. But reification of *methods* needs some clear reasoning. It's much simpler to look at Mark's (clipped) suggestions of a bare "o:m" as syntactic sugar for 

function (obj,method)
  return function (...) 
    return obj[method](obj, ...)
  end
end(o,stringify(m))

This doesn't have those philosophical questions lying around; it's just syntax. I dunno how much I'd use that, though. I think this is one of those features you just don't know how much you'd use until you started designing for it, and then of course it's too late.

Actually, I fixed the overly tight binding: my expansion looks up methods by name at invocation rather than at construction. I think the primary goal is coming up with a reasonable syntax for the expression; this is separable from trying to optimize out the table lookup. If you're trying to seek and destroy dynamicism overhead, I think you ought to be poking at the "from table import concat" designs and "static".

Jay