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
On Thu, Jun 18, 2009 at 9:14 AM, Gleb Alexeyev
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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe