Opened 4 years ago

Last modified 3 months ago

#5692 new bug

Source code with large floating constants in exponential notation cannot be compiled

Reported by: gracjan Owned by: pcapriotti
Priority: normal Milestone: 8.0.1
Component: Compiler Version: 7.2.1
Keywords: Cc: wren@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Compile-time crash Test Case:
Blocked By: Blocking:
Related Tickets: 5688 Differential Rev(s):
Wiki Page:


Source code cannot be compiled:

main = do
    print (123e124124124 :: Double)

where this one can be and will work after #5688 is fixed:

main = do
    print (read "123e124124124" :: Double)

Haskell Report forces Float and Double to go through Rational:

When exponent is big it produces very large Rational numbers. That takes a lot of time and usually ends in out of memory condition.

This is similar to #5688, but at compile time.

Change History (7)

comment:1 Changed 4 years ago by igloo

  • difficulty set to Unknown
  • Milestone set to 7.6.1

comment:2 Changed 3 years ago by pcapriotti

  • Owner set to pcapriotti

comment:3 Changed 3 years ago by igloo

  • Milestone changed from 7.6.1 to 7.6.2

comment:4 Changed 17 months ago by thoughtpolice

  • Milestone changed from 7.6.2 to 7.10.1

Moving to 7.10.1.

comment:5 Changed 11 months ago by thoughtpolice

  • Milestone changed from 7.10.1 to 7.12.1

Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone.

comment:6 Changed 3 months ago by thoughtpolice

  • Milestone changed from 7.12.1 to 8.0.1

Milestone renamed

comment:7 Changed 3 months ago by WrenThornton

  • Cc wren@… added

FWIW, the bytestring-lexing library has extremely efficient implementations of reading real literals for types which have limited precision (e.g., Float and Double). The functions in question are readDecimalLimited and readExponentialLimited in Data.ByteString.Lex.Fractional. The repo for the package also includes benchmarks.

Surely GHC doesn't need to optimize lexing quite so much as bytestring-lexing has done, but in the interest of minimizing code duplication/maintenance, I would be totally fine having bytestring-lexing become one of the core libraries GHC uses.

Note: See TracTickets for help on using tickets.