It seems to me that there's a choice here between (A) Full conformance to the letter of IEEE arithmetic AND full conformance to the letter of Haskell total ordering with consequent inconvenience: don't make floats Ord create new IEEE comparison operations for floats (B) Full conformance to the letter of IEEE arithmetic and letting Haskell total ordering fend for itself with consequent incoherence: the present situation (C) Full conformance to the letter of Haskell total ordering and letting IEEE comparison rules blow away in the wind: x == y if and only if x may be substituted for y in any expression with no change in behaviour, making -0.0 < 0.0 necessary I think, and extending ordering to order NaNs I haven't seen anyone advocate this, although it seems like an obvious thing to think about. (D) Revising the Haskell class hierarchy to have a new ConfusingOrd class with weaker laws than Ord, and making the floating point numbers instances of that. This would NOT extend Eq, so == (which identifies +0.0 and -0.0, though they behave differently) would not be available for floats. class ConfusingOrd a where (===) :: a -> a -> Bool (/==) :: a -> a -> Bool (<) :: a -> a -> Bool ... class (Eq a, ConfusingOrd a) => Ord a where x === y = x == y x /== y = x /= y ... compare :: a -> a -> Ord To my feeble mind, this looks like possibly being the least troublesome of the alternatives. Yes, we'd stop being able to sort collections of floats using compare, but there's a way around that. See (E). (E) Have two sets of floating point numbers: floats and ordered-floats, with explicit coercion from floats to ordered-floats that might fail and explicit coercion from ordered-floats to floats that always succeeds. To sort a list, we might do map fromOrderedFloat (sort [x | Just x <- map toOrderedFloat ys])