Lanny Ripple wrote:
Not really more efficient but plays to the language implementation's strengths.
Imagine
take 10 $ foo (10^9)
and
take 10 $ bar (10^9)
bar wouldn't evaluate until the 10^9 was done. (And I just ground my laptop to a halt checking that. :) foo on the other hand would run out to 10^6 and then conveniently finish the rest of your program waiting
s/10^6/10/ That's what I get for not proof-reading after making a change after the first proof-read.
for the need of the other 10^9-10 values. If you *always* needed the result of the 10^9 calculations then tail-recursion should be better since you won't be holding onto the evaluation frames.
-ljr
Peter Verswyvelen wrote:
Now if I understand this correctly, this just means that when writing something like:
foo n = if n<0 then [] else n : foo (n-1)
bar n = aux 0 [] where aux i xs = if i>n then xs else aux (i+1) (i:xs)
that foo is more efficient than bar because lazy evaluation of foo just puts the delayed computation in the "cdr" of the list, while lazy evaluation of bar has to keep track of all aux calls (the "closures") which gives much more overhead, maybe even stack overflow? Something like that? Thanks, Peter
--
Lanny Ripple