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 OAA09279; Mon, 6 Sep 2004 14:18:03 +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 OAA10039 for ; Mon, 6 Sep 2004 14:18:02 +0200 (MET DST) Received: from regyva.canterbury.ac.nz (regyva.canterbury.ac.nz [132.181.2.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id i86CI0EG013095 for ; Mon, 6 Sep 2004 14:18:01 +0200 Received: from CONVERSION-A1.it.canterbury.ac.nz by it.canterbury.ac.nz (PMDF V6.2-X27 #30791) id <01LEKE59D2WGDWONQD@it.canterbury.ac.nz> for caml-list@pauillac.inria.fr; Tue, 07 Sep 2004 00:17:58 +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 <01LEKE59692MDWP40L@it.canterbury.ac.nz>; Tue, 07 Sep 2004 00:17:58 +1200 (NEW ZEALAND STANDARD TIME) Date: Tue, 07 Sep 2004 00:17:58 +1200 From: Jason Smith Subject: RE: [Caml-list] laziness To: Jason Smith , skaller@users.sourceforge.net Cc: caml-list , Richard Jones Message-id: <413AB81F@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 413C5578.000 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 sourceforge:01 2004:99 bug:01 optimise:01 optimised:01 debugging:01 strictness:01 debugging:01 val:01 eagerly:01 haskell:01 compiler:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk >===== Original Message From skaller@users.sourceforge.net ===== >On Mon, 2004-09-06 at 19:07, Jason Smith wrote: > >> The compiler should optimize it out. There shouldn't be any need for using >> explicit print statements. > >Yes but the original issue is that the programmer >is seeing an expression they expect to be evaluated >and it isn't being evaluated -- so there is a bug >somewhere. I'm not sure i follow you here. How can you *not* use something? if you want to use an expression you "use" it, I'm sorry, I'm missing something obviously. >So your point is kind of backwards -- >the compiler may well optimise it away, but the programmer >is actually looking for evidence that it *isn't* >optimised away. Um, ok so ur depositing debug statements in code to check if the expression is still there. I still fail to see why u can't just *look* at your code and see if ur using the value or not. Can I get an example? >In an eager language, no conclusions can be drawn >from a debugging output - you still don't know >if the returned value is used or not. True, well almost true. The compiler can determine even in a strict language if the value is used or not, using strictness analysis. So you could put debugging statements in an expression and expect to see them and then volla, do not. For example, val f x y => x + 2; > f 2 (some computation that yields a number) 4 the long compuation was never actually used within 'f' so we don't have to evaluate it eagerly in haskell. Unforunately as I have already pointed out in a previous post in O'Caml it'd be harder to make this decision, but not impossible. >In a lazy language, debugging output indicates >the code *is* being used and hence not dead, Yup. >and lack of output means it isn't, at least >in one particular environment. Yup. >You might investigate further and discover the result >is only used in an unreachable branch of a match, >so the code really is dead: that function argument >will never be used (so you can remove it, >and also the unreachable branch). Ah nope, if its 'unreachable' then the original expression will never be evaluated, and you won't get the debug statements, and more so GHC won't compile it to start with. As soon as you use the expression, u reduce it. The *result* of evaluating the scrutinee expresion for a case (aka conditional expression) must be used because it determines the branch of the conditional to take. Weather that branch actually uses the result is irrelevant at that point. Cheers, Jason. ------------------- 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