[GHC] #15646: ghci takes super long time to find the type of large fractional number
GHC
ghc-devs at haskell.org
Fri Sep 28 12:04:21 UTC 2018
#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 simonpj):
> Why not do the parsing in compile time generate Core for this instead:
Yes, I agree. That's what I meant in comment:14 with `fl_before` etc, but
I expressed it badly. Let me try to do better. Accounting for monoidal's
excellent point we could have
{{{
data FractionalLit
= FL { fl_text :: SourceText -- How the value was written in the
source
, fl_neg :: Bool -- See Note [Negative zero]
, fl_mantissa, fl_exp :: Integer
-- Denotes <mantissa>E<exp>
}
}}}
So `1.077E400` would be represented with `fl_mantissa = 1077` and `fl_exp
= 397`.
Then we desugar to
{{{
Var 'makeRational' `App` (Lit 1077) `App` (Lit 397)
}}}
where `makeRational` is a new library function defined thus
{{{
makeRational :: Integer -> Integer -> Integer
makeRational i e = (i % 1) * (10 ^^ e)
}}}
Probably we want it to inline, but that's a separate matter.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:24>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list