> 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.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
