#12665: Make Read instances faster, and make them fail fast -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature request | Status: new Priority: high | Milestone: 8.2.1 Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:10 int-e]:
more prototypes for conversion from digits to an integer can be found here: http://int-e.eu/~bf3/haskell/FromDigits.hs ... `valInteger'` is the most interesting one of the bunch, and according to some preliminary testing, also the most efficient.
There's an unfortunate problem with the memoized base list. Once GHC knows the base, it pulls the `bs` base list up to the top level. If someone parses a very large integer, I believe we could be stuck with its base list indefinitely. Now it turns out that `ReadP` is defined `newtype ReadP a = R (forall b . (a -> P b) -> P b)`. If `Text.ParserCombinators.ReadP` exposed the `R` constructor and the `P` type (which it does not) then we could almost certainly trick GHC into thinking that `bs` depends on the passed `a -> P b` function. Since it does not, we're in a bit of a pickle. I think the best approach is probably to add an "internal" module that exposes all these details. For experimental purposes, I guess I can just use `unsafeCoerce`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12665#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler