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

[Julien Fischer]

Hi Mark,

On Mon, 16 Nov 2015, Mark Brown wrote:

> 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?

I think that's a good idea; I suspect most users have been assuming more
than that language actually guarantees anyway.

> 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?

If we are assuming IEEE 754 floats, yes.   For all of our current
backends that is definitely yes.

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

Do you mean along the lines of bug #146?  (The intended fix is that
the compiler should replace overflowing float literals with calls to
float.infinity/0 or -float.infinity/0.)

> char: Are these officially unicode now?

Yes.

> 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?

No, I can't see that it would cause any problems.

Julien.