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 IAA25080; Mon, 6 Sep 2004 08:10:39 +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 IAA23394 for ; Mon, 6 Sep 2004 08:10:38 +0200 (MET DST) X-SPAM-Warning: Sending machine is listed in blackholes.five-ten-sg.com Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id i866Aces031119 for ; Mon, 6 Sep 2004 08:10:38 +0200 Received: from warp (chateaudeau-4-82-225-176-25.fbx.proxad.net [82.225.176.25]) by postfix4-1.free.fr (Postfix) with SMTP id 0F08E181AC6; Mon, 6 Sep 2004 08:10:38 +0200 (CEST) Message-ID: <002101c493d8$61a6b1f0$19b0e152@warp> From: "Nicolas Cannasse" To: "Richard Jones" Cc: "caml-list" References: <413879B6@webmail> <20040906005741.GA20406@annexia.org> Subject: Re: [Caml-list] laziness Date: Mon, 6 Sep 2004 08:11:42 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Miltered: at concorde with ID 413BFF5E.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; cannasse:01 warplayer:01 caml-list:01 bug:01 bug:01 enums:01 extlib:01 unification:01 undecidable:01 assertion:01 cannasse:01 ocaml:01 nicolas:01 nicolas:01 laziness:02 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > Doesn't laziness often indicate a bug in the code? ie. You've > written an expression in the program, but that expression is never > used. This is dead code, right? Hence a bug? Laziness can be useful in some cases (eg : enums in ExtLib) and I use it for example in a typing algorithm where you need to duplicate big objects type for unification but you're not sure in advance which field(s) will be unified, so you delay it when they get accessed. It's kind of internet browser cache. Evaluated part of a program can depends on several kind of inputs, and is undecidable. Then you cannot make automated assertion about what part will never be evaluated in the general case (although this can be done in specific cases). However what you can do is automated flow analysis to check which part of your program are not accessible through some entry points : this is interesting for dead code removal and test coverage but can be tricky to do in OCaml. Regards, Nicolas Cannasse ------------------- 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