Julien Fischer
2015-11-15 22:38:28 UTC
Hi Mark,
than that language actually guarantees anyway.
backends that is definitely yes.
the compiler should replace overflowing float literals with calls to
float.infinity/0 or -float.infinity/0.)
Julien.
Moved to developers list...
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 moreWhile 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 charreference manual for comparison. Specifically that the order of functors in
a type declaration is significant. But I could not find it.
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?
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
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 currentcareful not to constrain implementations too much. Here are some
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?
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(Incidentally, for an overflowing float literal I get an error from
the C compiler about infinity being undeclared.)
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.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?
Julien.