[GHC] #13124: Template Haskell: Floating point literals that cannot be represented by rationals

[GHC]

#13124: Template Haskell: Floating point literals that cannot be represented by
rationals
-------------------------------------+-------------------------------------
        Reporter:  lerkok            |                Owner:
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Template Haskell  |              Version:  8.0.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by rwbarton):

 > One can easily imagine doing a similar transformation via TH, and having
 access to arbitrary floating constants would be useful. There would be no
 easy way to write that in TH today as all the "magic" constants would have
 to be converted to rationals, thus having anomalies.

 This doesn't make sense to me: any ordinary floating point value (i.e. not
 negative zero, infinity or NaN) can be exactly represented as a rational
 number. For those special floating point values, you could just generate
 an expression that evaluates to the `Double` you need, like `1.0 / 0.0`.
 Do you really need a literal specifically?

 In short, I don't see a real use case here.

 > I wouldn't go as far as saying that this is a huge shortcoming, but I
 don't see why TH can't just use a good old double/float there instead of
 requiring a Rational? Is there a good reason for requiring a Rational
 there?

 GHC doesn't use `Double` in any AST type. All floating point literals are
 represented internally as `Rational`. Considering the nasty and
 potentially platform-dependent semantics of `Double`, this is a good
 thing. Imagine cross-compiling to a hypothetical platform with 128-bit
 `Double`s on a platform that doesn't support that. (It's also certainly
 necessary to represent floating-point literals as `Rational` rather than
 `Double` or any other fixed-size data type, since `Rational` is itself a
 valid type for a floating-point literal!)

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13124#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler