#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 osa1): The discussion may be confusing but the proposed change is actually quite simple. Just refactor one type and follow the type errors. In more details: - Update the `FractionalLit` type as shown in comment:14. There are two variants, pick one. I'd pick the one with `fl_before`/`fl_after`/`fl_exp`. - `readRational` (the slow function that causes this ticket) is used by DynFlags and CmmLex too, so to keep things simpler let's keep the original `readRational` and add a new variant that returns `FractionalLit` (instead of `Rational`). This is the fast variant. - Replace `readFractionalLit` in Lexer.x with the new fast variant of `readRational`. Sounds like a good first ticket to me. Simon,
No, it won'r blow up when desugaring. Just desugar the constant to fromRational (readRational "1E1000"). Nothing blows up there!
But this relies on laziness, no? I thought you said this is not a good idea in comment:14. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15646#comment:18 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler