Joachim:
I do think that a class is needed. The IEEE754 is actually quite agnostic about floating-point types. What IEEE754 says about floats are the sizes of the exponent and the mantissa; let's call them E and M for short. Then, one can define a floating-point type for each combination of E and M, both of which are at least 2. The resulting type will fit into E+M+1 bits.
We have:
- "Float" is E=8, M=23. (And thus fits into a 32 bit machine word with the sign bit.)
- "Double" is E=11, M=52. (And thus fits into a 64 bit machine word with the sign bit.)
(In fact IEEE754 defines single/double precision to have at least those E/M values, but allows for larger. But let's ignore that for a moment.)
You can see that the next thing in line is going to be something that fits into 128 bits, also known as quad-precision. (Where E=15, M=112, plus 1 for the sign-bit.)
If we get type-literals into Haskell proper, then these types can all be nicely represented as "FP e m" for numbers e, m >= 2.
It just happens that Float/Double are what most hardware implementations support "naturally," but all IEEE-754 operations are defined for all precisions, and I think it would make sense to capture this nicely in Haskell, much like we have Int8, Int16, Int32 etc, and have them instances of this new class.
So, I'm quite against creating "fmaFloat"/"fmaDouble" etc.; but rather collect all these in a true IEEE754 arithmetic class. Float and Double will be the two instances for today, but one can easily see the extension to other variants in the future. (C already supports long-double to an extent, so that's missing in Haskell; as one sticking point.)
This class should also address rounding-modes, as almost all float-operations only make sense in the context of a rounding mode. The design space there is also large, but that's a different discussion.
-Levent.