Re: metamethod __lt oddity?

["Peter Hill" <corwin@...>]

>> It seems to be as you say, yet the pseudo-code for "__lt" in the manual
>> doesn't show this! Something is wrong somewhere.

RLake@oxfam.org.uk:
> The code clearly requires the objects to be of the same type for the __lt,
> __le, and __eq metamethods. (see lvm.c around line 210). So I suppose the
> documentation is wrong -- I would guess that the documentation has not
> been updated from Lua 4.
>
> The addition of the __eq method creates some problems; for one thing, it
> could make equality tests quite slow, and equality is tested quite a lot.

True, equality is indeed tested quite a lot, but how often on tables and
userdata (which are now the only types that can have metamethods) as opposed
to strings/numbers/etc?

The slowing down would only occur when objects that possessed metatables
were involved.


> Otherwise I will return to my original suggestion that there be two
> different equality operators, one of which is object equality and the
> other of which can be overridden (eg. == and ===).

Useful, but I don't think we need an extra symbol. We could have "raweq" to
test for raw equality, just like we have "rawget/rawset" for the indexing
symbol "[ ]".


On a slight tangent, the comparison metamethods don't include the full set
of possibilities:
    lt, le, gt, ge.

Instead they assume that these operators obey ordering properties, and so
get:
    (a < b) == (b > a)   -- so 'gt' can be discarded.
and
    (a <= b) == (b >= a)   -- so 'ge' can be discarded.

However, they then go on to acknowledge the further property that:
    (a <= b) == not (a > b) == not (b < a)
but they don't discard 'le' (or 'lt') leaving us with only one comparison
metamethod. They keep two, which could then be made contradictory. Why? If
the authors didn't want to supply the whole set (lt, le, gt, ge) why didn't
they just reduce it to a single operator?


*cheers*
Peter Hill.