Re: __eq in shared metatables

[Luis Carvalho <carvalho@...>]

Hi David,

Thanks for your thorough explanation. Please see my comments below.

<snip>
> The general rule for all this is summarized, I think, more clearly in PiL2,
> 13.4: "The metamethods for arithmetic and relational operators all define
> behavior for otherwise erroneous situations.  They do not change normal behavior
> of the language [though tables do allow this]"  Here, 3==4 and 3+4 are already
> defined in the language, so metamethods are not called for them.  Beginning Lua
> Programming (Chap 8) also has a good table "Metamethod Applicability" that
> summarizes when metamethods apply or not.

That makes a lot of sense now; I was considering metamethods as behavior
changers, not as behavior definers for out-of-normal situations.

<snip>
> > What about functions? I can understand why you don't have
> > individual metatables for functions
> 
> I actually recently came across a case where I thought that would be useful.
> 
> You can implement objects with functions rather than tables.  This is
> particularly convenient for callable objects.  However, you can't add fields to
> that object without overwriting the "global" metatable for functions (e.g. as in
> http://lua-users.org/wiki/MutableFunctions ) or converting it to a table.
> 
> Whether that is anything more than "nice to have in theory" though, I don't know.

We could at least support __eq for functions and threads, since they don't
have a "normal behavior". (A simple patch in luaV_equalval:

+    case LUA_TTHREAD:
+    case LUA_TFUNCTION: {
+      if (gcvalue(t1) == gcvalue(t2)) return 1;
+      tm = get_compTM(L, G(L)->mt[ttype(t1)], G(L)->mt[ttype(t2)], TM_EQ);
+      break; /* will try TM */
+    }

but I'm not sure if it's correct!)

If functions and threads deserve individual metatables is more debatable,
especially if you consider efficiency (I guess that would make functions
fatter, but I'm not knowledgeable enough to discuss this matter).

> > I'm all for __eq (and other comparisons for that
> > matter) being more "consistent". 
> 
> In the words of someone else, Lua is not "fully virtualizable": 
> http://lua-users.org/wiki/LuaVirtualization .  This causes issues of various
> severity, with __len being one of the more major ones.

I'd add lack of __pairs/__ipairs/__next, that is, customizable iterators. But
I digress. :)

> I think part of Lua's philosophy is to make design trade-offs at times when
> efficiency matters in the common case.  Another recent example of that is how
> concatenation is right-associative and limited to approximately 200 operands --
> http://lua-users.org/wiki/AssociativityOfConcatenation -- when it otherwise
> seems to make sense in theory for it to be left associative like most everything
> else.

I agree with this philosophy, but sometimes the trade-offs are not clear or
the design hurts consistency (especially if they are undocumented). I think
__eq for functions and threads still makes sense as it defines "otherwise
erroneous" behavior, and it would be nice to have them as extra mechanisms.

Cheers,
Luis.

-- 
A mathematician is a device for turning coffee into theorems.
        -- P. Erdos 

-- 
Luis Carvalho
Applied Math PhD Student - Brown University
PGP Key: E820854A <carvalho@dam.brown.edu>