And yet a lot of generic code is written in terms of compare.
That's can be an advantage, because often that code *should* blow up when it gets a NaN. E.g., sorting a list of Floats which includes a NaN.
Even deriving(Ord) only produces compare and relies on standard definitions for other methods.
I don't think that's actually a problem. Surely the IEEE Floating Point types would give their own definitions of not just compare but also <, <=, etc, overriding the problematic deriving(Ord) definitions of comparison in terms of compare and vice-versa.
Don't get me wrong, I don't think the current situation is ideal (although it doesn't seem all that bad to me). But this change would have far-reaching implications for performance which ought to be evaluated before it can be seriously considered, in my opinion.
Completely agree. The underlying issue is when a NaN should be treated like a Nothing, and when it should be treated like _|_. It seems clear that in some places the Nothing interpretation is preferred (say, arithmetic), and in other places _|_ (say, commanding the aperture of a therapeutic radiation device). It is a subtle issue, with effects on coding style, allowable code transformations both manual and automatic, correctness, and efficiency. --Barak.