Double -> CDouble, realToFrac doesn't work

[ross at soi.city.ac.uk]

[switching to libraries]

Recap: the definition of realToFrac as going through Rational loses the
NaN and +/-Infinity values of Double and Float (though GHC's RULES
bypass this).

On Thu, Nov 04, 2004 at 08:32:52PM +0100, Sven Panne wrote:
> It's an old thread, but nothing has really happened yet, so I'd like to
> restate and expand the question: What should the behaviour of toRational,
> fromRational, and decodeFloat for NaN and +/-Infinity be? Even if the report
> is unclear here, it would be nice if GHC, Hugs, and NHC98 agreed on 
> something.
> Can we agree on the special Rational values below?

[The proposal is to add 0:%0, 1:%0 and -1:%0 to Rational.]

Changing Rational from meaning rational numbers would also be bad.  I'd
prefer to redefine realToFrac to go through a new type that is the union
of Rational and these values.  That would mean adding extended variants
of toRational and fromRational to the Real and Fractional classes, with
default definitions but overidden for the Float and Double instances.
This type and the variant of fromRational might be usable for floating
point literals too.

> Printing those values could be more consistent for these systems, too, BTW.

True, though Hugs is already inconsistent with H98 in its printing of
floating point values.