From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id LAA00737; Mon, 6 Sep 2004 11:16:25 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id LAA01149 for ; Mon, 6 Sep 2004 11:16:25 +0200 (MET DST) Received: from cantvc.canterbury.ac.nz (cantvc.canterbury.ac.nz [132.181.2.36]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id i869GMtC021612 for ; Mon, 6 Sep 2004 11:16:24 +0200 Received: from CONVERSION-A1.it.canterbury.ac.nz by it.canterbury.ac.nz (PMDF V6.2-X27 #30791) id <01LEK7S098CGDWONQD@it.canterbury.ac.nz> for caml-list@pauillac.inria.fr; Mon, 06 Sep 2004 21:16:16 +1200 (NEW ZEALAND STANDARD TIME) Received: from webmail (cantwm.giga.canterbury.ac.nz [132.181.2.26]) by it.canterbury.ac.nz (PMDF V6.2-X27 #30791) with ESMTP id <01LEK7S06KACDWPJ3P@it.canterbury.ac.nz> for caml-list@pauillac.inria.fr; Mon, 06 Sep 2004 21:16:16 +1200 (NEW ZEALAND STANDARD TIME) Date: Mon, 06 Sep 2004 21:16:16 +1200 From: Jason Smith Subject: RE: [Caml-list] laziness To: Jason Smith Cc: caml-list Message-id: <413A8EF6@webmail> MIME-version: 1.0 X-Mailer: WebMail (Hydra) SMTP v3.61 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-WebMail-UserID: jns28 X-EXP32-SerialNo: 00002797 X-Miltered: at concorde with ID 413C2AE6.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; jns:99 canterbury:99 caml-list:01 haskell:01 haskell:01 'that:99 popping:01 exploited:01 closures:01 evaluates:01 ocaml:01 distinguish:01 mainstream:01 lazy:02 purely:02 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk >> 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