Re: Inconsistency in __eq, __lt, __le

["Dimiter \"malkia\" Stanev" <malkia@...>]

A bit off topic, but as comparison

Common Lisp has

eq, eql, =, equal, equalp, and few others.

eq - compares objects by pointer. It can't even guarantee that two 
identical values (otherwise) are "eq" because they might be different 
objects.

= - Just compares numbers.

eql - is like "eq" plus "=" , if both objects to compare are numbers, 
and are from the same type, and same value (obviously if NaN - > false). 
And also for characters (not in lua). I guess in lua would be for 
strings too

equal - is when both objects are structurally similar, but hard to 
explain in few words -
http://www.lispworks.com/documentation/HyperSpec/Body/f_equal.htm#equal

Now most interesting function (and slow) is

equalp - Also hard to explain in few words
http://www.lispworks.com/documentation/HyperSpec/Body/f_equalp.htm#equalp

But I've always remember it as "equal-printed" - e.g. If the two objects 
print the same way (serialize?) then they are equal. Not entirely the 
same, but close.

On 3/29/2011 7:40 AM, Kristofer Karlsson wrote:
> Consider the following simple example:
>
> Lua 5.1.4  Copyright (C) 1994-2008 Lua.org, PUC-Rio
>  > function T() return true end
>  > function F() return false end
>  > mt = {__eq = F, __le = F, __lt = T}
>  > t = setmetatable({}, mt)
>  > print(t == t, t < t, t <= t)
> true    true    false
>
> t == t gives true even though the __eq would return false, because it
> always returns true if the operands are the same object.
> t <= t and t < t however, honor the result of __le and __lt.
>
> This seems inconsistent to me.
> t <= t should always give true, by the same reasoning as t == t always
> is true
> Inversely t < t should always give false.
>
> So, I'd either prefer the same shortcut to be added for __lt and __le,
> or the shortcut be removed from __eq.
> At the very least, it would be nice with some sort of explanation on why
> the shortcut for __eq was added in the first place.
>
> /Kristofer