Greetings, As happens periodically, someone in #haskell brought up the following code snippet: [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 Doubles...). 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 that: http://hackage.haskell.org/trac/ghc/ticket/1997 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