Fwd: [Haskell-cafe] Re: curious about sum

[Alberto G. Corona]

However it does not work as I expected. I ´m interested in memory
management.
I though that

ghci> let l= [1..1000000]
ghci> foldl' (+) 0 l

would produce a stack overflow, since the list can not be freed, because l
points to the beginning of the list
however it succeed

My conclussion is that, in the case of sum, with the lazy evaluation,  isn´t
the list what is the cause of the stack overflow, but the lazy structure

0 + 1 +2 + 3 +4....

created by foldl before the final evaluation

I tried to test how I can force a stack overflow, in the strict case. Since
foldl' is strict,  the only way is to create a long long initial list.

ghci> let l= [1..100000000]  -- 100 times larger, two 0's added
ghci> foldl' (+) 0 l

as in the previous case, l will not garbage collect, and foldl' must build
the real list [1,2,3,4..]  . at the end perhaps a stack overflow willl be
produced

This is not the case in my windows system.ghc 6.10.1.   instead of that,
ghci grow to gigabyte size and more. I stopped the process or my machine
would be irresponsive.

My question is: Why the process does not grow also in the lazy case and
instead produces a stack overflow inmediately?

Yes I know that all of this is bizantine since strictness analysis would
solve this when compiled, but I think that there are somethig that i don´t
understand.

 It´s  a bug perhaps???

2009/6/18 Edward Kmett <ekmett at gmail.com>

> On Thu, Jun 18, 2009 at 9:14 AM, Gleb Alexeyev <gleb.alexeev at gmail.com>wrote:
>
>> Thomas Davie wrote:
>>
>>> No, I think it's extremely useful.  It highlights that numbers can both
>>> be lazy and strict, and that the so called "useless" lazy sum, is in fact,
>>> useful.
>>>
>>> But lazy sum should have beed defined in terms of foldr, not foldl. And
>> foldl is not strict enough for strict sum. Therefore the current choice in
>> the worst of both worlds.
>>
>
>
> I definitely agree with that sentiment.
>
> -Edward Kmett
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090618/201a03f2/attachment.html