I suspect that in computing 17 % 10000000000000000000000 we try to find
#15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston 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): the GCD of the two before we even start with fromRational, and you can see this isn't going to end well. It's not even GCD: just computing the nominator of 1e1000000000 in the binary representation requires at least `log2(10**1000000000)` bits of memory, which is over 396GB. If we'd like to fix this, I see the following options: a. Move computation of n,d from typechecking to desugaring. This should allow `:t 1e1000000000`, but `let x _ = 1e1000000000` will still crash. b. Add a method to `Fractional`, say `fromMantissaExp :: Integer -> Integer -> Integer -> a` that will be called instead of `fromRational`, with a default implementation that calls `fromRational`. This will allow `let x _ = 1e1000000000` to work, we could make it return Infinity for `Double`. This will likely have performance implications (I'm not sure if positive or negative). c. Change the representation of `Ratio` to have an extra constructor that represents numbers of the form `N / D * 10**E`. All those solutions need some extra special cases for `-XNumDecimals`. It's doable, I'm not convinced it's worth the maintenance cost but I won't protest if it's done. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15646#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler