From: Casey McCann

        Content-Type: text/plain; charset=ISO-8859-1

On Tue, Sep 20, 2011 at 8:20 PM, Daniel Fischer wrote:

...

However, nowadays I tend to think that making the Eq and Ord instances well-behaved (wrt the class contract) and having separate IEEE comparisons would overall be preferable. There is still the question whether all NaNs should be considered equal or not [and where Ord should place NaNs].

IEEE semantics are incompatible with Ord regardless. The problem can be fixed by changing Ord, removing the instance completely, or changing the instance to ignore the IEEE spec. I think the latter is the least bad option in the big picture.

I still don't see why it makes sense to add separate IEEE comparisons instead of just adding a standard partial order class, though. Surely posets are common enough to justify the abstraction, and it surprises me that one isn't already included. No doubt there are at least three or four different partial ordering classes on Hackage already.

I agree with this already, and will agree more strongly if ConstraintKinds become widely available.

...

Google suggests "Exception for NaN" from May.

Ah, yes, wherein someone suggested that comparing to NaN should be a runtime error rather than give incorrect results. A strictly more correct approach, but not one I find satisfactory...

I would consider this better than the current situation. At least your sets wouldn't be silently corrupted. John L.