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 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 <[EMAIL PROTECTED]>
ScmDB / Cisco Systems, Inc.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
