realToFrac issues

[Cale Gibbard]

On 27/02/06, John Meacham <john at repetae.net> wrote:
> I am not sure if this has been brought up for haskell-prime or not, but
> a while ago someone noticed that 'realToFrac' as specified in the report
> can't propagate NaN or infinity values properly since it goes through a
> Rational intermediate stage. this has the odd effect in ghc of making
> such conversions only work when optimization is used so the RULES
> turning Float<->Double conversion into their C counterparts fire.
>
> The proposed solution was to add NaN, +Infinity, and -Infinity to
> rational with the representations 0 :% 0, 1 :% 0, and -1 :% 0
> respectively. Seems straightforward, (and generally useful) but we
> should make sure not to forget it for haskell-prime.
>
>         John

I'm almost scared to ask: does this mean we need negative zero as well?

This change means that Rational is no longer a field. It makes me feel
uneasy at least. Should we really expect realToFrac to propagate those
values? Look at its type:
realToFrac     :: (Real a, Fractional b) => a -> b
Nothing about the Fractional class would seem to indicate that NaN and
+-Infinity should be representable. In fact, it just looks like the
basic field operations, and fields don't tend to have such elements
(not that we require the field axioms to hold for every instance).

I personally don't see any reason that realToFrac should propagate the
special error condition values of IEEE floating point types. Given its
type, I'd expect it to throw an exception.

 - Cale