[GHC] #13124: Template Haskell: Floating point literals that cannot be represented by rationals
#13124: Template Haskell: Floating point literals that cannot be represented by rationals -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently, TH expressions and patterns store Float/Double values as rationals: http://hackage.haskell.org/package/template- haskell-2.11.1.0/docs/Language-Haskell-TH-Syntax.html#t:Lit Unfortunately, this isn't sufficient, as there is no way to properly support usual floating point values such as NaN, Infinity, and Negative- Zero. This is true for both expressions and patterns. It would be nice if Double/Float literals were stored as double-floats themselves, instead of rationals. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13124 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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 goldfire): How would this new capability be accessed? I don't believe users can write non-`Rational` literals in Haskell, and so I wouldn't expect Template Haskell to be able to either. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13124#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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 lerkok): @goldfire That is a good point! But if TH aims at being able to produce constants of floats as a valid splice, then this will be an issue. Imagine a use case where someone uses template-haskell to "optimize" or "stabilize" numeric expressions. For instance, something like Herbie: http://herbie.uwplse.org/. There's already a GHC plugin for that: https://github.com/mikeizbicki/HerbiePlugin. 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. The other place this came up is in the FloatingHex library: https://hackage.haskell.org/package/FloatingHex-0.4. Currently this isn't a big issue there since literals supported are typically only positive ones, but one can imagine having a similar quasi-quoter that supported negative literals as well. Unfortunately, you cannot represent numbers such as "-0.0" (negative-zero!), as there is no way to write that as a rational number. (Note that negative-zero is a "valid" float, which can be told apart from the good old positive-zero.) 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? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13124#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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.
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
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. 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
#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 lerkok): @rwbarton Good point. I think it really comes down to special things like `NaN`, `Infinity` and `negative-zero` where the Rational representation just does not suffice. But perhaps that shortcoming doesn't warrant changing the AST and complicating the matters. I'm happy with a `wont-fix` decision here. This is clearly not the highest priority item in the TH story. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13124#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#13124: Template Haskell: Floating point literals that cannot be represented by rationals -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: wontfix | 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: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => wontfix Comment: I'll close this as wontfix as it isn't really compatible with the way GHC treats floating literals internally. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13124#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC