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 QAA22635; Sun, 5 Sep 2004 16:07:44 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id QAA20943 for ; Sun, 5 Sep 2004 16:07:42 +0200 (MET DST) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id i85E7dhN022788 for ; Sun, 5 Sep 2004 16:07:41 +0200 Received: from [192.168.1.200] (ppp210-32.lns2.syd3.internode.on.net [203.122.210.32]) by smtp3.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i85E7XHY090389; Sun, 5 Sep 2004 23:37:34 +0930 (CST) Subject: Re: [Caml-list] laziness From: skaller Reply-To: skaller@users.sourceforge.net To: Jon Harrop Cc: caml-list@pauillac.inria.fr In-Reply-To: <200409051150.39306.jon@jdh30.plus.com> References: <1094279400.3352.240.camel@pelican.wigram> <200409051150.39306.jon@jdh30.plus.com> Content-Type: text/plain Message-Id: <1094393252.3352.573.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 06 Sep 2004 00:07:33 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 413B1DAB.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 sourceforge:01 2004:99 optimising:01 strictness:01 referential:01 haskell:01 haskell:01 exploited:01 closures:01 9660:01 glebe:01 productive:01 ocaml:01 ocaml:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Sun, 2004-09-05 at 20:50, Jon Harrop wrote: > Are you asking if it would be productive to change the specs to something like > in-order evaluation? Thats the kind of question I'm asking (and others like it). A recent post actually discussed a language with a more complex evaluation strategy aimed at better optimisation opportunities. > I'm no expert but I think the non-specific order of > evaluation is a good opportunity for optimising and the strictness vs > laziness choices set OCaml in a nice position with regard to imperative > programming. I have some difficulty with the loss of referential transparency in Ocaml. Yes you can write purely functional code, but then at least one reason for eager evaluation (side effects) is lost. > 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: 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 .. :) -- John Skaller, mailto:skaller@users.sf.net voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net ------------------- 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