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 HAA04779; Sun, 5 Sep 2004 07:47:03 +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 HAA06906 for ; Sun, 5 Sep 2004 07:47:02 +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 i855l0Fq017712 for ; Sun, 5 Sep 2004 07:47:01 +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 i855kwHY077759; Sun, 5 Sep 2004 15:16:58 +0930 (CST) Subject: RE: [Caml-list] laziness From: skaller Reply-To: skaller@users.sourceforge.net To: Jason Smith Cc: caml-list In-Reply-To: <413879B6@webmail> References: <413879B6@webmail> Content-Type: text/plain Message-Id: <1094363217.3352.501.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 05 Sep 2004 15:46:58 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 413AA854.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 applicative:01 rephrase:01 optimiser:01 lazily:01 eagerly:01 haskell:01 optimiser:01 lied:01 optimise:01 preserving:01 semantically:01 9660:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Sun, 2004-09-05 at 11:07, Jason Smith wrote: > >Must they be evaluated before the function is called? > > If O'Caml follows the usual eager order semantics then evaluation is AOR or > Applicative order redection. (Which is what I use in Mondrian). > > There are several locations where we may attempt to reduce this overhead. Let me rephrase the question then. Suppose you wanted to reduce the overhead "almost all the time". You can't do this if you specify the usual eager semantics. So the question is: what changes to the semantic specification would allow the optimisations? For example: for 'simple' functions, it makes no difference if evaluation is eager or lazy, so the optimiser can choose to evaluate lazily if it is possible the result will not be used, or eagerly if it is used many times. Many functions programmers write will have this property. In a language where functions could have side effects, clearly you'd have to either make some statement about when and if the side effects occur, or simply exclude such a function from the optimisation. OTOH in Haskell I would guess there are only two properties which would prevent an arbitrary evaluation time: if the function could fail, or if it could fail to terminate. So if the function is pure, total, and terminating, there's no reason to specify when, if, or how many times it is executed. So you could, for example, simply allow the programmer to state a function is 'nice' to allow the optimiser maximum freedom (and on the programmers head it will be if they lied :) I'm not recommending this -- just giving an example of one way one might try to get around what seems to be a vast overconstraint for many functions in languages that mandate some rigid mix of eager/lazy semantics (and then try to optimise the result preserving the semantics). What would give the optimiser more freedom, without sacrificing the *ability* to use eager or lazy semantics when it is actually necessary semantically? -- 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