Strictness of enumFrom* on numeric types.

[Dan Doel]

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