Re: compare on Double

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?