Support for hexadecimal floats
Currently, Haskell only allows writing floating-point numbers in the decimal format. Unfortunately, writing floats in decimal/scientific format is not always the best option, due to loss of precision. As an alternative, there's the so called "hexadecimal floating point" format, described in p57-58 of: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
The format is rather simple, unambiguous, and relatively easy to implement. And it's been around for about 10 years by now.
It would be nice if the Haskell standard was changed to include such literals. But in the meantime, perhaps GHC can support such literals via a pragma, such as
LANGUAGE HexadecimalFloats or similar.
A corresponding pretty printer (similar to C's %a specifier) is also needed; which should go into the standard
Numerics module. Such a function can be called
showHFloat to accompany the similarly named functions for rendering float values.
A reference implementation can be given by template-Haskell splicing, and indeed the hackage package FloatingHex (http://hackage.haskell.org/package/FloatingHex) provides both a quasi-quoter for such literals, and the pretty printer
showHFloat. Unfortunately, this solution is less than satisfactory as it relies on the rather heavy mechanism for quasi-quotes, requires an extra library dependency, a pragma (
QuasiQuotes), and the import and dependency of a hackage package, which sounds a lot for just being able to write floats precisely!
Furthermore, Tempate Haskell has an issue with the storage of floats (https://ghc.haskell.org/trac/ghc/ticket/13124), which makes the library solution less than ideal in overflow cases. (Long story short: Template-Haskell stores floating literals as rationals, and thus has no reliable way of representing floats such as NaN, Infinity, and especially negative-zero.)
Numeric programming is important, especially in this new era of HPC, and many-core architectures tuned for crunching floating-point data seamlessly. While this is admittedly a minor step, I think it'll be a positive addition to GHC from a maturity perspective, and that of matching/leading other languages out there.