[Haskell-cafe] Justification for Ord inheriting from Eq?
robdockins at fastmail.fm
Fri Apr 7 09:38:23 EDT 2006
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
> 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
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
> Andrew Bromage
Speak softly and drive a Sherman tank.
Laugh hard; it's a long way to the bank.
More information about the Haskell-Cafe