Re: LUA4.0 : Bug with maths

[RLake@...]

> 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).

Two problems, both fairly minor:

1) Possibly my untamable desire for precise expression: total orders and
partial orders are semantically different in certain cases, and I
(personally) don't think this should be hidden. I'll yield on this.

2) It's not *quite* as efficient as the old solution, because it requires
two tag-method lookups in many cases. However, with Lua 4.1, unsuccessful
tag method lookups are cached so it may not matter much, so I'll yield on
that, too.

>> 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.)

I know, I know. But it did have to do with a possibly elegant (or possibly
stupid) redefinition of comparison operators as short-cutting
pseudo-predicates.

Another distraction: proper support for partial orders wants to have two or
three other type-despatched functions: "least greater", "greatest lesser",
and possibly "canonical". In the case of total orders, these are "max",
"min" and "identity". I definitely noticed the lack of those whilst writing
a LALR(1) parser generator in Lua. (Lua parser coming soon; I got the
classic calculator working last night, so I can't be far off. If only work
didn't get in the way so much....)

R.