Add Data.Float to base, add inf + nan

[brandonchinn178]

This proposal contains two parts, where the second part is the actual ask, and the first part is to create an appropriate location to implement it.

1. Add Data.Float to base (Export castWord32ToFloat, castFloatToWord32, castWord64ToDouble, castDoubleToWord64 from non-GHC.* module #378)
2. Add the following definitions to the new Data.Float module:

-- inf or -inf
inf :: RealFloat a => a
inf = 1/0

nan :: RealFloat a => a
nan = 0/0

There are certain cases where you want inf/nan as actual values in a Double field, and the two mechanisms to do so (inf = 1/0 or inf = read "Infinity") aren't very obvious.

[ChickenProp]

#378 is related. I think probably not everything from GHC.Float should be re-exported, but I don't have strong feelings on exactly what should and shouldn't. I'm not sure if there's any point in exposing eqFloat and eqDouble for example.

But I would like inf, negInf and nan. Not having them feels like an oversight to me.

[noughtmare]

Do we need negInf? I feel like -inf looks nicer, I'd say even (- inf) does not look much uglier if you really don't want to use LexicalNegation.

[konsumlamm]

I agree that it's a bad idea to reexport everything from GHC.Float. It contains a lot of functions using unboxed types and functions that are only used to implement typeclass methods. As far as I can tell, the only functions that aren't exposed somewhere else in some form are the ones I proposed to expose in #378. There I proposed to add Data.Float and Data.Double modules, for Float and Double related operations, respectively.

I think there should be a separate module (or several modules) for all the numeric classes, then inf, negInf and nan would belong in the same place as RealFloat. As prior art, MicroHs has a separate module for each numeric class, i.e. Data.Num, Data.Fractional, Data.Floating, Data.RealFloat, etc.

[brandonchinn178]

@noughtmare Good idea, removed negInf

[noughtmare]

If we already show and read "Infinity" and "NaN", wouldn't it make more sense to have pattern synonyms:

pattern Infinity <- ((\x -> 0 < x && isInfinite x) -> True) where Infinity = 1/0
pattern NaN <- (isNaN -> True) where NaN = 0/0

It's a bit sad that we can't make the pattern -Infinity work, but you can still at least write -Infinity as an expression.

Edit: applied Bodigrim's suggestion.

[TravisWhitaker]

Those pattern synonyms are an excellent idea.

[KovalevDima]

I had to define posInf, nan and negInf via Read type class for serialization tests in my library. It would be nice to have such functions in base

[treeowl]

IEEE 754 allows for multiple distinctive NaN values. Do we want to use this facility?

[Bodigrim]

pattern Infinity <- ((== 1/0) -> True) where Infinity = 1/0

I'd rather check x > 0 && isInfinite x than x == 1 / 0.

[hasufell]

@brandonchinn178 did you get enough feedback? If so, the next step would be to create a concrete GHC MR.

[brandonchinn178]

GHC ticket: https://gitlab.haskell.org/ghc/ghc/-/issues/26961
MR: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/15579

[konsumlamm]

I'm not convinced that the Formatting and Operations sections should be exposed.

Formatting

showFloat is already exposed by Numeric and the other items are only used to implement showFloat and the Show instances for Double and Float. They're also not really documented.

Operations

floatToDigits and fromRat are already exposed by Numeric, while integerToBinaryFloat' is a helper for implementing fromInteger for Double and Float and fromRat' is a helper for implementing fromRat.

[brandonchinn178]

Sure, I just found all functions that mentioned RealFloat. I can remove