Re: [Haskell-cafe] Justification for Ord inheriting from Eq?

On Apr 7, 2006, at 1:36 AM, ajb@spamcop.net wrote:

G'day all.

Quoting Robert Dockins :

...

Ewwwwww! Be careful how far you depend on properties of typeclasses, and make sure you document it when you do.

The behaviour of NaN actually makes perfect sense when you realise that it is Not a Number. Things that are not numbers are incomparable with things that are.

Yes, NaN can be of type Float. But it's not a Float.

If you take that tack, then you have to concede that the type system isn't doing what it should (keeping me from having something not-a- float where I expect a float). Any way you slice it, its an unfortunate situation. I'd personally rather that any operation generating NaN raises an exception, a la divide by 0 at Int. I think (although I'm not sure) that the floating point infinities play nice wrt equality and ordering, so getting rid of NaN would restore at least _some_ semblance of proper algebraic behavior to the floating point representations. (And the FFI already has CFloat/CDouble, so you should use those when you really need to actually do something with NaN generated by external code, and CFloat/CDobule should not be members of Eq and Ord). Or at the very least, attempting to compare NaN using (==) or (<) and friends should raise an exception, rather than just returning broken results.

Cheers, Andrew Bromage

Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG