Fix toRational and realToFrac for Float and Double

[Bodigrim]

The pitfalls of toRational and realToFrac are well-known:

• https://hackage.haskell.org/package/base-4.21.0.0/docs/Prelude.html#v:realToFrac
• https://github.com/NorfairKing/haskell-WAT#real-double
• https://ro-che.info/articles/2019-05-14-convert-cdouble-to-double

> toRational (read "Infinity" :: Double)
179769313486231590772930519078902473361797697894230657273430081157732675805500963132708477322407536021120113879871393357658789768814416622492847430639474124377767893424865485276302219601246094119453082952085005768838150682342462881473913110540827237163350510684586298239947245938479716304835356329624224137216 % 1
> toRational (read "NaN" :: Double)
269653970229347386159395778618353710042696546841345985910145121736599013708251444699062715983611304031680170819807090036488184653221624933739271145959211186566651840137298227914453329401869141179179624428127508653257226023513694322210869665811240855745025766026879447359920868907719574457253034494436336205824 % 1

> realToFrac (read "NaN" :: Double) -- With -O0
Infinity
> realToFrac (read "NaN" :: Double) -- With -O1
NaN

> realToFrac (read "NaN" :: Double) :: CDouble
Infinity
> realToFrac (read "NaN" :: CDouble) :: Double
Infinity

This all can be fixed with

 instance  Real Double  where
+    toRational x
+      | isInfinite x = if x > 0 then GHC.Real.infinity else -GHC.Real.infinity
+      | isNaN x = GHC.Real.notANumber
     toRational (D# x#)  =
         case integerDecodeDouble# x# of ...

(Is GHC.Real.infinity hacky? Definitely. But infinitely better than returning 2696539702293... and 300 more digits)

Earlier discussion: https://mail.haskell.org/pipermail/haskell-prime/2006-February/000791.html

The MR is available at https://gitlab.haskell.org/ghc/ghc/-/merge_requests/14413

[Bodigrim]

CC @NorfairKing

[augustss]

I like this. It's what MicroHs already does. No need to have an obvious footgun like toRational.

[hasufell]

My guess is this would mostly just break some obscure unit/golden tests, which doesn't seem too bad.

[NorfairKing]

My guess is this would mostly just break some obscure unit/golden tests, which doesn't seem too bad.

Yes, and it would "break" my WAT list: https://github.com/NorfairKing/haskell-WAT#real-double

[nh2]

Thank you @Bodigrim for investing your time into cleaning up these historical messes!

Not having 100s of small gotchas keeps Haskell a modern, sensible language, and saves lots of people time and hacks.

Type system correctness isn't the only correctness we need; the values also have to be right!

[augustss]

You might want to consider preserving -0 as well. It's nice when converting between floating types.

[cartazio]

this plus lennarts suggestion sounds nice. looks good to me

(i have a now ancient sketch of how to improve some related api stuff on the ghc tracker i should make more legible when i find some time)

[ivanperez-keera]

@RyanGlScott anything this would break in Copilot?

[RyanGlScott]

If anything, I'd say that Copilot is currently broken (in a subtle way) because of this issue, and fixing this issue would improve Copilot. See Copilot-Language/copilot#633.

[cartazio]

https://gitlab.haskell.org/ghc/ghc/-/issues/16519#note_488041 This little design sketch I wrote a while ago talks about one way to fix some of the underlying issues. I’ve some time this summer to flesh it out if there’s interest /appetite to support something in that direction

[augustss]

Don't let the perfect be the enemy of the good. Making realToFrac work by a hack is not perfect, but it sure is better than the current situation.