[Haskell-cafe] Why is toRational a method of Real?

[Henning Thielemann]

On Wed, 4 Aug 2010, John Meacham wrote:

> The numeric classes are sort of messed up when it comes to non integral
> values.  (not that they are perfect for other things) for instance,
> realToFrac doesn't preserve NaN or Infinity,

Why should realToFrac do this? NaN, Infinity and +/-0 are IEEE hacks for 
the common numerical applications you do with floating point numbers. 
These special values could be supported by floating point specific, or 
even IEEE specific type classes, but they should not be part of 
mathematically motivated type classes .

> and the rounding functions discard information too by trying to convert 
> a floating point value to an integral one...

What else shall a rounding function return if not integers?

> I was probably going to introduce a 'FloatMax' type in jhc that is
> guarenteed to be able to represent all values representable by native
> floating point types, then replace the use of Rational as an
> intermediate type with it.. not that that helps things right now really.

Integer and Rational represent all possible integers and rationals, 
respectively, apart from memory restrictions. They are not very efficient, 
but that's why GHC's optimizer rules replace common conversions by more 
efficient conversions.