RE: [Caml-list] laziness

[Jason Smith <jns28@student.canterbury.ac.nz>]

>> I'd have thought that you cannot determine evaluation order in a purely
>> functional language and, therefore, you couldn't distinguish between eager
>> and lazy evaluation in this case.
>
>That isn't so if you can have functions that fail or fail to terminate.
>In those case laziness matters.
>Clearly that's more cases than
>you'd guess, otherwise Haskell would be a pointless language:

A function in haskell 'that fails to terminate' will either recurse ad 
infinitum. In which case thats the programmers fault, if Haskell evaluates it 
and it doesn't stop, ur problem.

Or, it will recurse over a Sum type. Haskell like most mainstream functional 
languages does not support recursive types, therefore we have to structure it 
explicitly over the Sum data type. With this you can create 'infinite' data 
structures, e.g.

fib = 1 : 1 : [ a + b | (a, b) <- zip fib (tail fib)]

we can keep on accessing this list by popping of the head element "forever".

>I'm not a Haskell programmer but I imagine the laziness is actually
>exploited (just as Ocaml programmers exploit HOF's and closures
>so routinely we forget we're doing it until some C++ programmers
>asks if we actually use such advanced features .. :)

Laziness is a *very* usefull feature, you can save *huge* amounts of unneeded 
calcluations. Any recursive data structure be it binarytree's, octtree's, 
lists etc.. benefits from this, you only evaluate expressions in the structure 
*when u need them* i.e. when u need there WHNF values, say in a condition 
statement.

Jason.


p.s. John skaller, I was wondering why I keep getting undeliverable errors 
when I send things to your address?

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners