Casey McCann
It would improve things in the sense of giving well-behaved instances for Eq and Ord, yes. It would not improve things in the sense that it would violate the IEEE floating point spec.
I'm not intimately familiar with IEEE 754, but in any case we'd be in good company: R typically lets you select to sort NaNs as greater or less than any other values, and sorts non-NaN values correctly also in the presence of NaNs, I think. At any rate, I think we already violate the spec by not having the required "unordered" result for comparisons, and just treating every comparison involving a NaN as "GT". I don't think considering NaN as e.g. less than -Inf would violate the spec *more*.
The current situation is an awkward compromise that mostly works and does what you want in most cases except when you get weird silent bugs due to, say, minimum returning a non-minimal value, or Data.Map.lookup returning Nothing for a key that actually exists, or whatever else.
This sounds pretty bad, until you consider that you don't even have proper equality, so using floating point values as keys in a Map is already asking for trouble. But I would like sorting to work more consistently. But I guess it is a matter of lipstick on a pig... -k -- If I haven't seen further, it is by standing in the footprints of giants