[GHC] #15646: ghci takes super long time to find the type of large fractional number
GHC
ghc-devs at haskell.org
Mon Sep 24 05:15:06 UTC 2018
#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
More information about the ghc-tickets
mailing list