compare on Double

[Chris Kuklewicz]

I have another proposal: make different types.

People who want integers have the choice of Int (or Int64, etc) for performance
or Integer for stronger algebraic guarantees.

I suggest Double be split into types with different guarantees:
  One that avoids "error" (and has weird NaN / Inf behavior)
  Another that avoids having or propagating NaN/Inf by always throwing an error.
  And perhaps an IEEE type with specific Nan/Inf behavior ?

So (0.0/0.0 :: Double) is NaN and (0.0/0.0 :: FiniteDouble) is an error.

The same applies to Float/FiniteFloat:

newtype FiniteDouble = FiniteDouble Double
newtype FiniteFloat = FiniteDouble Float

Is there some reason to avoid this solution?