#15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): In this part: {{{ , fl_before, fl_after, fl_exp :: Integer -- Denotes <before>.<after>E<exp> }}} I would be careful with `fl_after`: we don't want to merely convert the part after the dot to an integer, because 1.2e3 and 1.02e3 are not the same. I think we could always shift the dot and exponent so that we always have a whole number before "e" (e.g. 1.2e4 -> 12e3, 0.1e-4 -> 1e-5) Regarding desugaring to `readRational "1e100"`, do I understand correctly programs would then have to parse `1e100` every time a floating literal is evaluated? My feeling is that this will affect negatively performance (but it's just a feeling - I suggest benchmarking before checking this in.) One more complication is hexadecimal floats, which have the same problem (`:t 0x1.0p100000000` is slow) I know I've said this and I already sound like a grouch, but I still prefer just to forbid big exponents and call it a day. There are less than 1e90 elementary particles in the observable universe, doubles go up to 1e308 and rarely used extended floating point representations only slightly further. If someone wants to write `2e10000000000000` we might just ask them to write the code as `2 * 10^^10000000000000` instead. This at least has a chance to work given an appropriate type and typeclass instance, unlike computing this expression as integer which is hopeless. After all, Haskell is about moving problems at run time to problems at compile time, not the other way around. (I don't want to stir up an argument here. If you disagree, you can just ignore what I said, I won't insist.) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15646#comment:20 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler