Ben Franksen <ben.franksen@[EMAIL PROTECTED]
> wrote:
> Jon wrote:
[...]
> > Prelude> Data.List.foldl (+) 0 [1..1000000]
> > *** Exception: stack overflow
> >
> > The first (strict) implementation works but the latter lazy
implementation
> > stack overflows in GHC. Will it stack overflow in the next Haskell
> > implementation (if there were one)? Who knows. Apparently it doesn't
stack
> > overflow in Hugs. [...]
> [...] Nothing here is unpredictable, it's mostly a matter of
> non-strict semantics.
I disagree. What is unpredictable here is whether or not an unspecified
Haskell implementation is smart enough to evaluate the fold strictly. It
is unpredictable, because it falls outside the Haskell definition (AFAIK).
An implementation may or may not evaluate the above fold strictly; strict
evaluation would be legal in this case.
Now, in this case, the programmer should, of course, use a strict fold.
The problem is that algorithms that ac***ulate a bounded size result given
a possibly very long input are very common. This means that it is very
easy to accidentally introduce space leaks in a lazy language. On a smart
implementation or small inputs, a particular program may work just fine.
On a naive implementation or larger inputs, the same program might leak
space like a pig. Furthermore, a change to the program --- possibly even
far far away from a place where strict evaluation should have been used
--- may trigger a space leak, because space usage in a lazy language
depends on the run-time behavior of both producers and consumers or the
change might just happen to foil the strictness analyzer.
-Vesa Karvonen
|
