[GHC] #15646: ghci takes super long time to find the type of large fractional number

[GHC]

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

 In this part:

 {{{
        , fl_before, fl_after, fl_exp :: Integer
                                    -- Denotes <before>.<after>E<exp>
 }}}

 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. I think we could always shift the dot and exponent so that we always
 have a whole number before "e" (e.g. 1.2e4 -> 12e3, 0.1e-4 -> 1e-5)

 Regarding desugaring to `readRational "1e100"`, do I understand correctly
 programs would then have to parse `1e100` every time a floating literal is
 evaluated? My feeling is that this will affect negatively performance (but
 it's just a feeling - I suggest benchmarking before checking this in.)

 One more complication is hexadecimal floats, which have the same problem
 (`:t 0x1.0p100000000` is slow)

 I know I've said this and I already sound like a grouch, but I still
 prefer just to forbid big exponents and call it a day. There are less than
 1e90 elementary particles in the observable universe, doubles go up to
 1e308 and rarely used extended floating point representations only
 slightly further. If someone wants to write `2e10000000000000` we might
 just ask them to write the code as `2 * 10^^10000000000000` instead. This
 at least has a chance to work given an appropriate type and typeclass
 instance, unlike computing this expression as integer which is hopeless.
 After all, Haskell is about moving problems at run time to problems at
 compile time, not the other way around. (I don't want to stir up an
 argument here. If you disagree, you can just ignore what I said, I won't
 insist.)

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646#comment:20>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler