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