#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: type 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 Johannkokos): The problem seems to be specific to scientific notation literals. On GHCi, Both {{{ 10^1000000 :: Double }}} and {{{ :t 10^1000000 :: Double }}} terminate near-instantly, while there is a noticeable delay with {{{ 1e1000000 :: Double }}} and {{{ :t 1e1000000 :: Double }}} . ''Comment on reddit by /u/duplode'' -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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: | -------------------------------------+------------------------------------- Changes (by JulianLeviston): * owner: (none) => JulianLeviston -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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 JulianLeviston): Seems to be picking `Double` as the type... I noticed that `Double` over `1e309` parses as `Infinity`... {{{#!shell ghc git:(master) ✗ time ./inplace/bin/ghc-stage2 blah2.hs -ddump-tc -dppr- debug [1 of 1] Compiling Blah2 ( blah2.hs, blah2.o ) TYPE SIGNATURES (main:Blah2.$trModule{v r1} [lidx] :: ghc-prim:GHC.Types.Module{tc 622}) :: ghc-prim:GHC.Types.Module{tc 622} (main:Blah2.largeValue{v rpX} [lid] :: ghc-prim:GHC.Types.Double{(w) tc 3k}) :: ghc-prim:GHC.Types.Double{(w) tc 3k} TYPE CONSTRUCTORS COERCION AXIOMS Dependent modules: [] Dependent packages: [base, ghc-prim, integer-gmp] blah2.hs:1:1: ==================== Typechecker ==================== {<no location info>} ((main:Blah2.$trModule{v r1} [lidx] :: ghc-prim:GHC.Types.Module{tc 622}) :: ghc-prim:GHC.Types.Module{tc 622}) = ghc-prim:GHC.Types.Module{d 625} {<no location info>} (ghc-prim:GHC.Types.TrNameS{d 62b} {<no location info>} "main"#) {<no location info>} (ghc-prim:GHC.Types.TrNameS{d 62b} {<no location info>} "Blah2"#) {blah2.hs:3:1-22} {blah2.hs:3:1-22} (largeValue{v aLS} [lid] :: ghc-prim:GHC.Types.Double{(w) tc 3k}) :: ghc-prim:GHC.Types.Double{(w) tc 3k} [LclId] main:Blah2.largeValue{v rpX} = {blah2.hs:3:14-22} 1e1000000 (base:GHC.Real.fromRational{v 02C} {<no location info>} 1e1000000) <> ./inplace/bin/ghc-stage2 blah2.hs -ddump-tc -dppr-debug 0.27s user 0.21s system 96% cpu 0.505 total }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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 osa1):

The literal 1e100 means fromRational (100...000 :: Rational), as specified in Haskell report

Where is this specified in the report? I can see the syntax in section 2.5 which links to sections 3.4 and 6.4.1 but I can't see this rule in any of those linked sections. Can't find where the semantics for this literal is defined.

It's not surprising it crashes badly when the exponent has 10 digits or more.

Wait, are you saying that typing `1e1234111111111111111111111` to take minutes and use up more than 20G of memory (residence, not allocation!) not surprising? Perhaps I'm completely lost then. Could you elaborate on how is this not surprising? FWIW I just typed in that expression in Python REPL and it gave me an answer in an instant.

With -XNumDecimals, we need to process the literal before we can tell its type: 1.234e3 is a valid Integer but 1.234e2 is not.

I'm still not convinced that we can't do better but OK. At the very least we should be able to type those expressions quickly when `-XNumDecimals` is not enabled (which is the default). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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 osa1):

a floating point literal like 1e100 means fromRational (n % d) where "the integers n and d are chosen so that n/d = f"

But finding the n and d should happen after type checking, no? Why idoes this even effect type checking time? Shouldn't `:t` just do type checking? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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: | -------------------------------------+------------------------------------- Changes (by alpmestan): * cc: alpmestan (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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 osa1): So, to summarize the problem here: - Semantics of a floating point literal (which is in our case in `XeY` form) is defined as `fromRational (n % d)`. - So we need to find and `n` and `d` such that `fromRational (n % d)` gives us our float. - As per Haskell 2010 chapter 6.4.1 (note that section 2.5 only gives the syntax, not the type) `fromRational` has type `Fractional a => Rational -> a` so `fromRational (n % d)` has type `Fractional a => a` - So `XeY` form always has type `Fractional a => a` ! - Currently we tokenize an `XeY` we call `readRational__` on the string `"XeY"`, which returns this: `(n%1)*(10^^(k-d))`. `n`, `k` and `d` are parsed from the input so this is very cheap (in our example `n` is `X`, `k` is `Y`, `d` is `0`). - However, evaluating `(10^^_) :: Rational` part of the expression takes long time and uses a lot of memory. Indeed, as comment:10 says, if you have 1000000000 as the exponent then representation of this number takes GBs of memory so this is expected. - comment:12 asks why rendering `Infinity` takes this long: that's because we generate the `Infinity` value during desugaring (after parsing), and for this we have to first generate the `Rational` value for the literal first (which is what is taking all the time and using all the memory). You can observe this if you run ghci with `-fdump-parsed -fdump-ds` and evaluate `1e100000 :: Float`. Perhaps it makes sense to distinguish these two problems: - Type checking is too slow - Generating `Infinity :: Float` is too slow (a) in comment:10 fixes (1) but not (2). (c) in comment:10 fixes (1), and it may also fix (2) if we could somehow use this new constructor fields to return `Infinity` without calculating `10^^e :: Integer` first (as far as I understand the new consturctor will look like: `ExpRational n e -- stands for (n%1)*(10^^e)`). However, (c) means a change in a public type, and we'd need to evaluate performance changes etc. caused by turning a product type to a sum type (more optimizations apply to product types than sum types! at least until we improve demand analysis for sum types and use unboxed sums in WW). Also, I'm not sure if adding one more constructor to a library type just for this is a good idea. We'd need to think about how/whether to expose this to users (perhaps we do want to expose it in `Data.Ratio` somehow). This means long discussions and bikeshedding etc. What to do? I think delaying evaluation `readRational` until it's needed by making some code lazier would work. Looking at the lexer, we generate a `ITrational` for this literal like this: {{{ tok_float str = ITrational $! readFractionalLit str readFractionalLit :: String -> FractionalLit readFractionalLit str = ((FL $! (SourceText str)) $! is_neg) $! readRational str where is_neg = case str of ('-':_) -> True }}} Notice how we're very deliberately strict here. My guess is that simply removing strictness around `readRational` (e.g. the `$!` in `readFractionalLit`) may fix this. If it doesn't then some other code down the line needs to be made lazier too. However I'm not sure if this causes other problems (the fact that the thunk for `readRational str` will keep the `str` alive is not a problem because the `str` only holds the string for the literal). We'll have to evaluate this change in strictness somehow. If we follow this route then we'd also need to add a test to make sure typing this expression remains fast (strictness properties are hard to maintain ...). Here's another idea that is like (c) but does not need changes in a public type: duplicate the `Ratio` type so that only the version used by GHC has the special constructor. The code gen and `Data.Ratio` will still use the current type. Now we can use the special constructor in lexing to avoid evaluating a huge `Integer`, and only when desugaring we do some kind of evaluation (this is where we can perhaps be smart and generate `Infinity` efficiently, or in the worst case we end up with the current situation, but with fast type checking). None of these solutions strike me as particularly satisfying though... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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 osa1): That sounds good to me. Just to make sure, the proposed solution will still blow up when desugaring, so currently we aim to fix the type checking, right? Or am I missing something about the proposed solution? One problem with removing `fl_value` may be that any users of this type (maybe source plugins?) will have to provide a string instead of an actual float (we currently allow users to only give a value and omit `fl_text` by passing a `NoSourceText`). I don't know if there are any users (can it be used by source plugins?) of this type but maybe it's worth checking. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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: | -------------------------------------+------------------------------------- Changes (by JulianLeviston): * owner: JulianLeviston => (none) Comment: Removing myself as owner because this has gone well beyond the small simple patch I was hoping for one of my first tickets :) Hopefully someone else can pick it up. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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 simonpj):

But this relies on laziness, no?

No, it doesn't rely on laziness. At no stage will GHC construct that Rational. The desugarer will generate something like {{{ Var 'fromRational' `App` (Var 'readRational' `App` Lit (LitString "1e100")) }}} That is, it'll generate Core that will, when compiled and run, compute the rational (at runtime). But the compiler just manipulates this Core data structure, there is no bad Rational in it. Does that help? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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 simonpj):

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.

Excellent point.

Regarding desugaring to readRational "1e100", do I understand correctly programs would then have to parse 1e100 every time a floating literal is evaluated?

No; it'll be floated to top level, and done once in the run of the program.

I would still prefer to forbid big exponents and call it a day.

The difficulty is then you have to pick what is "big"; and one day it'll bite us. So we'll add a compiler flag, etc. It doesn't smell, to me, like something that should cause the program to be rejected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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 osa1): Hmm, I'm not sure if doing parsing in runtime is a good idea. Why not do the parsing in compile time generate Core for this instead: {{{ (X GHC.Real.% 1) GHC.Num.* (10 :: Integer) GHC.Real.^^ Y }}} for `XeY`? Now the huge `Integer` will be computed in runtime but we won't be doing parsing. I just realized that this is basically desugaring `XeY` to `(X%1) * 10^^Y`, similar to the idea in comment:20 except we don't ask users to write this, instead we convert the `XeY` notation to the other. Simon, any opinions on this? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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 osa1): OK, that makes sense. JulianLeviston, feel free to ping me on IRC if you have any questions -- or let us know here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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 JulianLeviston): Chatted a bit more with osa1 about this now on IRC. Seems TH has the same issue(s), because the use-sites for `mkFractionalLit` includes the `cvtOverLit :: Lit -> CvtM (HsOverLit GhcPs)` function from hsSync/Convert.hs... the `cvtOverLit (RationalL r)` clause, which reads: ``` cvtOverLit (RationalL r) = do { force r; return $ mkHsFractional (mkFractionalLit r) } ``` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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 osa1): Right, so just to summarize what JulianLeviston said in my words and give a concrete example, in this program: {{{ {-# LANGUAGE TemplateHaskell #-} module Lib where import Language.Haskell.TH foo :: Q Exp foo = [| 1e1000000 |] }}} we use the same problematic code path when parsing the quasi-quotation and end up calculating a huge `Integer` when parsing (which can be seen easily with `-ddump-parsed-ast`). This much is probably obvious if you're familiar with TH internals. This will be fixed when we update the parser. The actual problem is we desugar this quasi-quote to: {{{ foo = litE (rationalL (GHC.Real.:% @ Integer <huge integer> 1)) }}} where `litE` is simply `return . LitE` and `rationalL` is `RationalL`. `RationalL` takes a `Rational` argument, which is what we're trying to avoid doing in compile-time. Furthermore, because these are [http://hackage.haskell.org/package/template-haskell-2.13.0.0/docs /Language-Haskell-TH-Syntax.html#t:Lit public types] they are hard (if not impossible) to change. I see two options: - Do the computation when generating the TH quasi-quote expressions (during desugaring, in `DsMeta`). This way the TH syntax wouldn't change (we would generate exactly the same desugared expr for this program), and the example above would take forever to compile. - Add one more literal constructor to TH syntax that looks like our new `FractionalLit` for this purpose. Then we could use our new desugaring (comment:23) in `Convert.hs` when we actually splice the expression. So both quasi-quote compilation and splicing remain fast. Any thoughts? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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 JulianLeviston): Update: Been working on this today; I've done the changes required in `BasicTypes.hs` and I'm on `Lexer.hs` changes now. It's going well, currently in the process of refactoring `readHexRational` to use a new function for reading the significand and exponent out of hex floating literals. (from `Util.hs`). Just finished doing that for `readRational`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:31> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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): Would you like to lay out the design, and its moving parts, in a draft Note that will eventually be part of the source code? eg I think (but am not sure) that your question is this: in representation of a literal fractional number: {{{ 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> } }}} in what number base is the `fl_exp` expressed? For example * `1.7e30` has `fl_mantissa = 17`, and `fl_exp = 29`, assuming base 10 * But what about `0x5e.ff2p12`? Here the mantissa can reasonably still be `0x5eff`, but the exponent must (presumably, given [http://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html #hexadecimal-floating-point-literals the spec]) be in base 2. To me it sounds as if we need another field for the exponent base to accurately represent the literal. So the value of the literal is `mantissa * (base ^ exponent)`. My instinct is just to make the a sum-type rather than another `Int` or `Integer`: {{{ data ExponentBase = Base10 | Base 2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:33> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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 JulianLeviston): Here's my suggested draft, so far: {{{ data FractionalLit = FL { fl_text :: SourceText -- How the value was written in the source , fl_neg :: Bool -- See Note [Negative zero] , fl_signi :: Integer -- The significand component of the literal , fl_exp :: Integer -- The exponent component of the literal , fl_exp_base :: FractionalExponentBase -- See Note [Fractional exponent bases] } data FractionalExponentBase = Base2 | Base10 -- Note [fractional exponent bases] For hexadecimal rationals of -- the form 0x0.3p10 the exponent is given on base 2 rather than -- base 10. These are the only options, hence the sum type. See also #15646. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:35> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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 osa1): Right, so there's a brief discussion about this in comment:29, however we can't convert a `Rational` to the new `FractionalLit` type so the idea doesn't quite work. Changing TH syntax is not easy becuase it's a user-facing type (would need a proposal). One idea comes to mind is to make `FractionalLit` a sum type, with an alternative for the old `FractionalLit` values: {{{ data FractonalLit = FL { ... } -- | TemplateHaskell fractional lit: we lose information during conversion -- from Haskell syntax to TH syntax (happens when desugaring quasiquotes, in -- DsMeta) where we convert a `FL` to a `Rational` because that's what TH -- syntax wants. | THFL { fl_text :: SourceText , fl_next :: Bool , fl_value :: Rational } }}} Then we can propose a change to the TH syntax, depending on the result we can remove the `THFL` constructor. Alternatively, Simon suggests finding an approximate conversion of a `Rational` to the new `FractionalLit` in comment:30. That'd fine to get the code to compile but it won't be mergeable until the conversion is fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:37> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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 JulianLeviston): I got it compiling and typechecking, then set about writing a test. Discussed with you (osa1) and a couple others in IRC about writing tests. Looked more into how the testing framework works, read up on writing tests. Pretty sure I can figure that out now (it's really not going to be hard, once I read all the test guides). So that's fine, but I had an issue compiling after doing a `git pull` (for some reason I had to recompile stage 1 of the compiler again), so I recompiled and thought I'd try out my changes. So I typechecked a large scientific notational literal, and it got `*** Exception: No match in record selector thfl_value` I realised immediately that was because I'd just made the types match in the desugarer and renamer by using the new TH part of the FractionalLit type because the desugarer talks bout pattern group matching on HsFractional and seemed to expect a Rational. So, the `PatGroup` data type, has a constructor `PgN :: Rational -> PatGroup` which I'm now going to refactor to be `PgN :: Integer -> Integer -> PatGroup`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:39> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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 JulianLeviston): Okay... I think I've put all the pieces into place now. I'm a little confused as to why, but `dsLit` seems to still be taking a while to desugar with the `fromRational (readRational txt)` pattern in place. I'm not 100% sure I've done what was intended... {{{ HsRat _ fl ty -> do let txt = case fl of THFL { thfl_text = SourceText t } -> t FL { fl_text = SourceText t } -> t val = fromRational (readRational txt) num <- mkIntegerExpr (numerator val) denom <- mkIntegerExpr (denominator val) return (mkCoreConApps ratio_data_con [Type integer_ty, num, denom]) }}} However if I do `./inplace/bin/ghc-stage2 --interactive` then `:t 1e10000000` and it takes over 3 seconds still. (One less digit takes under 1 second) so the bug is still there — it's now taking *less* time to typecheck, but the desugarer seems to still be catching me out. I'll attach a patch file so you can see what I've done to now. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:41> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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 osa1): Could you submit your patch to Phabricator? It's really hard to review it this way. I haven't looked at the patch in details yet, but the desugaring in comment:41 is not right. We want to avoid building a rational in compile time (the `Integer` components of `Rational` is what's taking all the time), but that's what you're doing in the code in comment:41 (in `readRational`). See comment:24 for how we want to desugar this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:42> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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 JulianLeviston): Have been trying to create the expression referred to by SPJ in comment:24 in `MatchList.hs` but having trouble creating core. {{{ HsRat _ fl ty -> case fl of FL { fl_signi = i, fl_exp = e } -> return (mkApps (Var "makeRational") [(mkIntegerExpr i) (mkIntegerExpr e)]) }}} I don't know how to make a `Var`. The `String` above is clearly wrong, but I couldn't find out how to construct one from scratch. I read through `MkId.hs`, `Id.hs` and `Var.hs` but it's not clear to me what I should be doing. Also, comment:24 refers to making "a new library function" which seems easy enough, but I don't know what a library function is (like... where should it go such that it gets picked up at runtime and registered in the list of available variables, available to core?). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:44> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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 JulianLeviston): Still floundering :). Anyone have any suggestions about the following? it's still just as slow as before, it seems. {{{ HsRat _ fl _ -> case fl of FL { fl_signi = fl_signi, fl_exp = fl_exp } -> do mkRational <- dsLookupGlobalId mkRationalName litI <- mkIntegerExpr fl_signi litE <- mkIntegerExpr fl_exp return ((Var mkRational) `App` litI `App` litE) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:46> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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 JulianLeviston): Thanks for the direction. Apologies for taking so long to get back; I've had the flu. `-v3` output is fascinating (thanks, I wasn't aware of it), because nothing is marked as slow. I'll look into building a profiled compiler. The pause happens immediately before `1e100000000 :: Fractional p => p` is output. Here's the output for anyone following along's interest: {{{ Expanse:ghc julian$ ./inplace/bin/ghc-stage2 -v3 -Rghc-timing -e ':t 1e100000000' Glasgow Haskell Compiler, Version 8.7.20181012, stage 2 booted by GHC version 8.4.3 Using binary package database: /Users/julian/code/haskell/ghc/inplace/lib/package.conf.d/package.cache package flags [] loading package database /Users/julian/code/haskell/ghc/inplace/lib/package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.3 wired-in package integer-wired-in mapped to integer-gmp-1.0.2.0 wired-in package base mapped to base-4.12.0.0 wired-in package rts mapped to rts wired-in package template-haskell mapped to template-haskell-2.14.0.0 wired-in package ghc mapped to ghc-8.7 *** Parser [source]: !!! Parser [source]: finished in 0.83 milliseconds, allocated 0.489 megabytes *** Desugar: *** Simplify [expr]: !!! Simplify [expr]: finished in 0.64 milliseconds, allocated 0.367 megabytes *** CorePrep [expr]: !!! CorePrep [expr]: finished in 5.45 milliseconds, allocated 5.770 megabytes *** ByteCodeGen [Ghci1]: !!! ByteCodeGen [Ghci1]: finished in 0.52 milliseconds, allocated 0.488 megabytes Loading package ghc-prim-0.5.3 ... linking ... done. Loading package integer-gmp-1.0.2.0 ... linking ... done. *** gcc: gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -B/Users/julian/code/haskell/ghc/libraries/base/dist-install/build --print-file-name libiconv.dylib *** gcc: gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -B/Users/julian/code/haskell/ghc/libraries/base/dist-install/build --print-file-name liblibiconv.dylib *** gcc: gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -B/Users/julian/code/haskell/ghc/libraries/base/dist-install/build --print-file-name iconv.lib *** gcc: gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -B/Users/julian/code/haskell/ghc/libraries/base/dist-install/build --print-file-name libiconv.lib *** gcc: gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -B/Users/julian/code/haskell/ghc/libraries/base/dist-install/build --print-file-name libiconv.dll.a *** gcc: gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -B/Users/julian/code/haskell/ghc/libraries/base/dist-install/build --print-file-name iconv.dll.a *** gcc: gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -B/Users/julian/code/haskell/ghc/libraries/base/dist-install/build --print-file-name libiconv.a *** gcc: gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -B/Users/julian/code/haskell/ghc/libraries/base/dist-install/build --print-file-name iconv.a *** gcc: gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -B/Users/julian/code/haskell/ghc/libraries/base/dist-install/build --print-file-name libiconv *** gcc: gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -B/Users/julian/code/haskell/ghc/libraries/base/dist-install/build --print-file-name iconv Loading package base-4.12.0.0 ... linking ... done. Search directories (user): Search directories (gcc): *** Parser [source]: !!! Parser [source]: finished in 0.15 milliseconds, allocated 0.153 megabytes *** Desugar: *** Simplify [expr]: !!! Simplify [expr]: finished in 0.32 milliseconds, allocated 0.203 megabytes *** CorePrep [expr]: !!! CorePrep [expr]: finished in 0.16 milliseconds, allocated 0.112 megabytes *** ByteCodeGen [Ghci1]: !!! ByteCodeGen [Ghci1]: finished in 0.31 milliseconds, allocated 0.299 megabytes *** Parser [source]: !!! Parser [source]: finished in 0.20 milliseconds, allocated 0.215 megabytes *** Desugar: *** Simplify [expr]: !!! Simplify [expr]: finished in 0.35 milliseconds, allocated 0.224 megabytes *** CorePrep [expr]: !!! CorePrep [expr]: finished in 0.15 milliseconds, allocated 0.089 megabytes *** ByteCodeGen [Ghci1]: !!! ByteCodeGen [Ghci1]: finished in 0.36 milliseconds, allocated 0.351 megabytes *** Parser [source]: !!! Parser [source]: finished in 0.09 milliseconds, allocated 0.043 megabytes 1e100000000 :: Fractional p => p Leaving GHCi. *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: <<ghc: 223511272 bytes, 80 GCs, 12572972/49798120 avg/max bytes residency (9 samples), 154M in use, 0.000 INIT (0.003 elapsed), 4.102 MUT (4.434 elapsed), 0.172 GC (0.187 elapsed) :ghc>> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:48> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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 osa1): I think profiled GHC may not help that much because we already have a good idea of what's going wrong. I'd print `litI` and `litE` in the desugaring code you showed in comment:46 and see if any of the integers are huge. Remember that the root cause is that we build huge integers in compile time and we're trying to avoid that. If this is still taking too long then we somehow still build huge integers in compile time. Given that we only build two integers, one them them should be the culprit. Printing would show us which one, and then we can figure out the rest. Can you push your code on a git repo and give us the remote/branch? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:50> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Good find. Indeed that's a duplicate. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:52> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): Here's my PR to my forked GHC branch: https://github.com/JulianLeviston/ghc/pull/1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:54> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): I got my build building again. I'm not sure why my interface files went out of sync. I guess I should re-read and watch the videos about the pipelines and stages. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:56> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): Sorry I've been distracting myself with thinking about 15617 and 3372. I'll switch back to this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:58> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1):

I can't print out litE and litI because they don't have a show instance for Core

In GHC you should be using `Outputable` instances (with `pprTrace` and frieds). Most GHC types don't have a `Show` instance, but most have `Outputable`. In this case `pprTrace "..." (text "litI:" <+> ppr litI <+> "litE:" <+> ppr litE)` should work.

So... yeah, this is what happens when I run it:

Right, so the problem is in your `mkRational` name definition: {{{ mkRationalName = tcQual gHC_REAL (fsLit "mkRational") mkRationalIdKey }}} You're saying that `mkRational` lives in `GHC.Real`, but that's not the case. It actually lives in the GHC module `BasicTypes`. We need to put `mkRational` to somehwere in `base`. `GHC.Real` is a good place I think. Secondly, I see some uses of `mkRational` in `BasicTypes`. Those also need to be moved, because when booting GHC, when building stage 1, we'll be using a GHC that won't have `mkRational` in `GHC.Real`. So all those definitions that use `mkRational` need to be moved to `GHC.Real` too. Does this make sense? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:60> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): Ok, so I compiled and added in the line: {{{pprTrace "..." (text "litI:" <+> ppr litI <+> text "litE:" <+> ppr litE) $ pure ()}}} ... however that's in `MatchLit`, so doesn't get executed when typechecking, only when evaluating. Makes sense because if I typecheck, I still get the slow behaviour, but if I evaluate, I get that error (coz I still haven't updated the location of `mkRational` yet). So, this also seems correct, given I have made zero changes in the typechecker so far. So I'm looking in to that. I hope I'm on the right track. I ran it with `./inplace/bin/ghc-stage2 -e ":t 1e289" -ddump-parsed-ast` and it responded with something that ended with: {{{ ==================== Parser AST ==================== (Just ({ <interactive>:1:1-5 } (BodyStmt (NoExt) ({ <interactive>:1:1-5 } (HsOverLit (NoExt) (OverLit (NoExt) (HsFractional (FL (SourceText "1e289") (False) (1) (289) (Base10))) (HsLit (NoExt) (HsString (SourceText "noExpr") {FastString: "noExpr"}))))) (SyntaxExpr (HsLit (NoExt) (HsString (NoSourceText) {FastString: "noSyntaxExpr"})) [] (WpHole)) (SyntaxExpr (HsLit (NoExt) (HsString (NoSourceText) {FastString: "noSyntaxExpr"})) [] (WpHole))))) }}} And, seeing `HsOverLit` in this output, and looking at `tcExpr` in `compiler/typecheck/TcExpr.hs`, it seems to match the `HsOverLit` clause, which calls `newOverloadedLit` from `compiler/typechecker/Inst.hs`, which I'm not 100% sure, but it seems to be *not* matching on a short cut clause, and so applying `newNonTrivialOverloadedLit`. I'll take another pass at understanding it all again tomorrow. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:62> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): As discussed on IRC, try to get it compiling for now and then we can worry about where to put the functions. [https://github.com/JulianLeviston/ghc/pull/1/files#diff- 199051a796530164d94214a54aadd294R1216 In this line] you specify `mkRational`s module as `GHC.Real` so that's where it should be. When you do that your `dsLookupGlobalId` call should work. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:64> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): Here is the current summary of what I've been intending to do: Problem is excessive duration of typechecking large fractionals. Initial issue was renamer and desugarer were consructing the rational before typechecking. The plan that has been implemented is to adjust FractionalLit to store the significand and the exponent, as well as the FractionalExponentBase (because the fractional *may* be hex or dec) instead of just a rational, and to parse the source as an application of a new library functions `mkFractionalLit` and `mkTHFractionalLit`. In the process we also added a new core expression `mkRationalExpr` Template haskell still uses a rational to represent its fractional lits, so we have *two* constructors in the FractionalLit type: FL and THFL (one for regular literals and one for Template Haskell literals). We also had to adjust the lexer in the parser to deal with parsing the values into the new forms. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:66> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): Ah, after reporting those problems, I thought to myself... "let's try re- running `./boot` and `./configure` after moving the definitions of `mkRational`, `mkRationalWithExponentBase`, `FractionalExponentBase` and `rationalFromFractionalLit` to `GHC.Real` again to see if it actually bootstraps the files like I thought it might, and it seems it did (I obviously still have a lot to learn ;-)). Still, got many other compiler errors, but it at least it seems to be doing the right thing. I'm still fairly unsure about how exactly I can extract all the pieces I need to to put these functions into `GHC.Real` (or somewhere available)... Here are the errors (which make sense): {{{ libraries/base/GHC/Real.hs:832:13: error: Not in scope: type constructor or class ‘Data’ | 832 | deriving (Data, Show) | ^^^^ libraries/base/GHC/Real.hs:841:30: error: Not in scope: type constructor or class ‘FractionalLit’ Perhaps you meant ‘Fractional’ (line 194) | 841 | rationalFromFractionalLit :: FractionalLit -> Rational | ^^^^^^^^^^^^^ libraries/base/GHC/Real.hs:842:28: error: Not in scope: data constructor ‘FL’ Perhaps you meant ‘F#’ (imported from GHC.Base) | 842 | rationalFromFractionalLit (FL _ _ i e expBase) = | ^^ libraries/base/GHC/Real.hs:844:28: error: Not in scope: data constructor ‘THFL’ | 844 | rationalFromFractionalLit (THFL _ _ r) = r | ^^^^ make[1]: *** [libraries/base/dist-install/build/GHC/Real.o] Error 1 make: *** [all] Error 2 }}} So, I'll keep pottering along and see if I can't make it compile. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:68> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Julian, can you please paste the exact error you are experiencing as I don't see how `Problem 1` can arise. When we bootstrap GHC, we first compile stage1 with stage0. So no problems here as the call to lookup `mkRational` is made when stage1 is run. When we build stage2, we first build prelude with stage1, including `GHC.Real` so there might be some problems here if a module needs to call `mkRational` before `GHC.Real` is compiled but this is hard to debug without any error messages or other information to be going from! I think at this point it would be very useful if you put your code up as a MR so that people can comment directly about what needs doing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:70> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): https://gitlab.haskell.org/ghc/ghc/merge_requests/55 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:72> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): Rebased the MR. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:74> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): Ok. Back to having the error above again, now. I'll try moving all the types and functions around `FractionalLit` into `GHC.Real` again now, and hope that importing them into BasicTypes makes sense from there (seems weird to me, but I dno't really understand how it works fully, I guess — feels like I'm trying random stuff without understanding it, which is definitely not how I like to work). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:76> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): I duplicated the library code into both `GHC.Real` and left it in `BasicTypes.hs` as well as per osa1's suggestion on IRC. Got this error after running `./boot && ./configure && make -j4` {{{ libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.hs:5:1: error: Bad interface file: libraries/ghc-prim/dist-install/build/GHC/Tuple.hi mismatched interface file versions (wanted "80720181230", got "80720181219") | 5 | import GHC.Tuple () | ^^^^^^^^^^^^^^^^^^^ make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:78> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): Thanks os1. I did `make clean`. Then the error became: {{{ libraries/base/GHC/Real.hs:839:21: error: Not in scope: type constructor or class ‘SourceText’ | 839 | = FL { fl_text :: SourceText -- How the value was written in the source | ^^^^^^^^^^ libraries/base/GHC/Real.hs:849:25: error: Not in scope: type constructor or class ‘SourceText’ | 849 | | THFL { thfl_text :: SourceText -- How the value was written in the source | ^^^^^^^^^^ }}} and a bunch more errors of a similar type... at which point you suggested removing `SourceText`, but that'd require rewriting all the functions, so ... yeah, now I believe you're looking up the ticket again and refreshing your brain with it :) :thx: -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:80> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): It's currently on gitlab, ulysses4ever -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:82> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): In the process of finalising the ticket. Working on test failures and adding an additional test. Shouldn't be too long now :) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:84> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler