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

[Robert Dockins]

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

> G'day all.
>
> Quoting Robert Dockins <robdockins at fastmail.fm>:
>
>> 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