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 AAA02996; Fri, 23 Jul 2004 00:17:14 +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 AAA02953 for ; Fri, 23 Jul 2004 00:17:13 +0200 (MET DST) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i6MMHASH023854 for ; Fri, 23 Jul 2004 00:17:12 +0200 Received: from [192.168.1.200] (ppp205-61.lns1.syd3.internode.on.net [203.122.205.61]) by smtp1.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i6MMGx4Y019840 for ; Fri, 23 Jul 2004 07:47:02 +0930 (CST) Subject: [Caml-list] lazy evaluation: [Was: kprintf with user formatters] From: skaller Reply-To: skaller@users.sourceforge.net To: caml-list In-Reply-To: <20040722173901.A18239@pauillac.inria.fr> References: <200407211552.RAA04351@pauillac.inria.fr> <200407212141.45191.postmaster@jdh30.plus.com> <20040722173901.A18239@pauillac.inria.fr> Content-Type: text/plain Message-Id: <1090534619.5870.125.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 23 Jul 2004 08:16:59 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 41003CE6.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; kprintf:01 formatters:01 sourceforge:01 2004:99 pierre:01 weis:01 lazyness:01 side-effect:01 eagerly:01 lazily:01 optimiser:01 prematurely:01 curiously:01 haskell:01 prematurely:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Fri, 2004-07-23 at 01:39, Pierre Weis wrote: > However, the very match expression you > mentioned has indeed something of a lazyness behavior, since it is > indeed equivalent of an ``if ... then ... else ...'' construct, as > I know you know :) I'm intrigued! Felix has a side-effect free functional subsystem, and I expected this to buy considerable optimisation opportunities unavailable in Ocaml: in particular, any functional code which is normally evaluated eagerly can always be evaluated lazily (which the optimiser effects by converting it to procedural goto-spagetti). However, erroneous or non-terminating lazy code can't be prematurely evaluated in either language I'd kind of assumed this could be done in Felix, but it is clear now this isn't the case. This seems to indicate in hybrid languages like Ocaml and Felix well specified parts of the language must be deemed eager or lazy: both languages support expicitly procedural constructions, however even the functional code in both languages seems to need the evaluation time specified (to more extent than I'd believed previously..) Curiously this seems to indicate that in the long run Haskell compilers should be able to generate more efficient code if only the optimisers are smart enough to prove it is both correct and efficient to evaluate something prematurely. One of my friends is actually doing a thesis on this. His technique is basically to make everything eager by default, and then upgrade it to lazy if necessary (rather than the other way around). -- 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