[Haskell-cafe] Proper Handling of Exceptional IEEE Floating Point Numbers

[Barak A. Pearlmutter]

> 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.