Strictness of enumFrom* on numeric types.
dan.doel at gmail.com
Fri Jul 25 19:06:46 EDT 2008
As happens periodically, someone in #haskell brought up the following code
[1..] !! 1000000 :: Integer
When evaluated, that causes a stack overflow, because enumFrom currently
returns a list of increasingly nested thunks for Integers (and Floats and
The ensuing discussion, however, brought something I hadn't seen before to
light: this shouldn't (I think) be the case, per the Haskell 98 report. In
the section "Predefined Types and Classes", it is specified:
For all four of these Prelude numeric types, all of the enumFrom
family of functions are strict in all their arguments.
Which would, I believe, have the side effect of making a straightforward
implementation of the functions element-strict, thus preventing the stack
overflows (to confuse matters, the later reference implementation of the
functions for Floats and Doubles in instead non-strict, but that can probably
be looked at as a bug in the report).
Currently, I believe only Int (of the four listed in the report) has a proper
implementation for all the functions. For instance
length (take 3 (enumFrom undefined))
is undefined for Ints, but is 3 for Integers, Floats and Doubles, so that at
least is a bug. enumFrom*To are, of course, correct by necessity.
Anyhow, given the above text in the report, it seems reasonable to me to make
the functions stricter for the above types (and any Ints and Words of various
lengths if they have similar problems). There is, in fact a trac ticket for
and a patch, evidently. But dons thought it would be appropriate to alert this
list, as well (it is the maintainer, after all).
Thanks for your time,
-- Dan Doel
More information about the Libraries