
dbenbenn:
Since it's possible to support laziness for Integer (while still avoiding any stack overflow), I think it makes sense to do so. What if you have some big complicated program like the following:
x = some big slow computation y = [x..]
lots of code
z = length $ take 10 y
Why bother computing x if you don't have to? And as an added benefit, if you keep laziness, you don't have to worry about possibly breaking any programs that depend on the current lazy behavior.
Laziness would NOT make sense for Int, since Int is bounded. You can't tell how long [(x::Int) ..] is without evaluating x.
On 12/22/07, Don Stewart
wrote: People shouldn't be writing code that depends on this!
One of the main features of Haskell is that it's lazy. I don't think it's wrong to write code that depends on laziness.
Depending on laziness if fine, but depending on undefined strictness semantics for particular types is more fragile. Whether Int or Bool or whatever type has a strict or lazy accumulator in enumFromTo is entirely unspecified -- you can't look up the report to check. -- Don