Paterson, Ross wrote:
Roman Leshchinskiy writes:
Daniel Fischer wrote:
Proposal: Provide Double and Float with Eq and Ord instances that introduce a total order.
I'm strongly against this, for the reasons that have already been mentioned. and because there a good reasons for why the IEEE semantics is the way it is.
But compare cannot implement the IEEE semantics and be total, because the Ordering type cannot represent "unordered". Something has to give. The nearest compare can do is to throw an exception if an argument is NaN (with compatible behaviour from the comparison operators).
Why can't compare just specify that its results are undefined when applied to NaN? As a matter of fact, the Haskell report already does this. It explicitly says that the results of evaluating expressions like 0/0 are undefined which means that applying compare to them produces undefined results as well.
At least that would not be silent or subtle breakage.
IMO, if we really want to avoid silent breakage we shouldn't have silent NaNs by default. That is, evaluating 0/0 should throw an exception. Unless I'm mistaken, this can be implemented by simply setting the appropriate processor flag. Personally, I would be much more open to a proposal to make this the default as long as there is no runtime cost and silent NaNs can be turned back on somehow if a program needs them. Roman