2008/5/10 Edsko de Vries [EMAIL PROTECTED]:
The key reason why nested additions take stack space, is because (+) on
Integers is *strict* in both arguments. If it were somehow non-strict
instead, then the unevaluated parts of the number would be heap-allocated
rather than stack-allocated.
I
Hi,
No, the thunks are (usually) stored on the heap. You don't get the
stack overflow until you actually force the computation at which point
you have an expression like:
(...(((1+2)+3)+4) ... + 1000)
which requires stack in proportion to the number of nested parentheses
(effectively)
Edsko de Vries [EMAIL PROTECTED] wrote:
(...(((1+2)+3)+4) ... + 1000)
which requires stack in proportion to the number of nested parentheses
Ah, that makes! So does it make sense to talk about tail recursive
thunks? Or does the evaluation of thunks always take stack space
On Thu, 2008-05-08 at 23:29 +0100, Edsko de Vries wrote:
Hi,
How can I know whether something will be stack or heap allocated? For
example, in the standard example of why
foldl (+) 0
will fail to evaluate a long list of integers due to a stack overflow,
but foldl' won't, it is pointed
Edsko de Vries wrote:
sum :: Tree - Int
sum t = sum' [t] 0
where
sum' [] acc = acc
sum' (Leaf i : ts) acc = sum' ts $! (i + acc)
sum' (Node l r : ts) acc = sum' (l : r : ts) acc
Because of $!, you should compare the Leaf case to foldl', not foldl.
The Node case can be said to
