[m-dev.] [m-users.] Comparison in the reference manual

[Mark Brown]

Moved to developers list...

On Mon, Nov 9, 2015 at 10:09 AM, Paul Bone <paul at bone.id.au> wrote:
>
> While answering a question on IRC I tried to find the relevant part in the
> reference manual for comparison.  Specifically that the order of functors in
> a type declaration is significant.  But I could not find it.

Regarding the more general question, the standard orderings for char
and string are documented as system-dependent in the corresponding
library modules.

I'm quite sure ints and floats were intended to have the mathematical
ordering, with the usual caveats about floating point equality; I know
I have written code that relies on this. But it's undocumented and
thus undefined, strictly speaking.

Tuples are undocumented. Comparison for pred and func types can't be
implemented, so the point is moot.

I'm wondering, can the language define a bit more than it has thus
far? The idea would be to provide some useful theorems, while being
careful not to constrain implementations too much. Here are some
suggestions:

int: Define it as having the mathematical ordering, and require
implementations to disallow overflowing literals. The latter is so you
don't have 9223372036854775808 < 0 being true. (You may still have
9223372036854775807 + 1 < 0, since the + operation is undefined on
overflow.)

float: We can at least say that < and > never contradict the
mathematical ordering, even if = can due to lack of precision. Can we
assume implementations may use +/- infinity? Otherwise a caveat on
overflowing float literals may be needed. (Incidentally, for an
overflowing float literal I get an error from the C compiler about
infinity being undeclared.)

char: Are these officially unicode now? We could define them as having
the code point ordering.

string: There are probably good reasons to keep this ordering
undefined. But maybe we could say something about the ascii subset?

tuples: These exist as a convenience to the user. Would defining them
as having the obvious ordering be likely ever to cause problems for
implementations?

Thoughts?

Mark