Re: LUA4.0 : Bug with maths

[Reuben Thomas <rrt@...>]

> Reuben Thomas:
>
> > So for those who didn't believe me before (when I merely wanted to
> > compare sets), here's a solid real world reason for fixing ordering!
>
> Me:
>
> I'll repeat what I said last time (in response to Reuben): that's fine, but
> keep your hands off of "==".

I did! I did! All my rules above used <=!

:-)

> If Lua were to go down that path, I would recommend keeping the "lt" tag
> method exactly as it is, and adding a "partial_le" tag method attached to
> whatever the partial-less-than-or-equal-to operator turns out to be; in the
> absence of the "partial_le" tag method, partial-order comparators could try
> for an "lt" tag method before deciding that the objects are incomparable.

It seems much neater to me to keep "lt" as at present, add my "le" tag,
and then use the "lt" rules if there is no "le" tag method (i.e. things
work as at present), the "le" rules if there is no "lt" tag method (i.e.
easy to make partial orders work) and both sets if they're both defined
(which is more efficient, as the < and > rules take two comparisons if
there's only an "le" method).

This is backwards compatible, as efficient as the old solution, and copes
with partial orders. What's the problem? There's no need to introduce new
operators (except that it might be nice to have an === or somesuch to
allow non-identity equality).

> What value should P return if the predicate is not true, false or nil?

(And just note that this has nothing to do with partial ordering
comparisons, which only need to return a true value and a false value,
just as for total orders.)

-- 
http://sc3d.org/rrt/ | egrep, n.  a bird that debugs bison