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 VAA01454; Tue, 22 Jun 2004 21:19:07 +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 VAA01387 for ; Tue, 22 Jun 2004 21:19:06 +0200 (MET DST) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i5MJJ1SH020374 for ; Tue, 22 Jun 2004 21:19:03 +0200 Received: from [192.168.1.200] (ppp215-31.lns1.syd2.internode.on.net [203.122.215.31]) by smtp3.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i5MJIdHY077153; Wed, 23 Jun 2004 04:48:41 +0930 (CST) Subject: Re: [Caml-list] unused function detection From: skaller Reply-To: skaller@users.sourceforge.net To: Eric Dahlman Cc: caml-list , Nicolas Cannasse , David MENTRE In-Reply-To: <525AEC07-C47B-11D8-A9FD-000393914EAA@atcorp.com> References: <1087924126.3755.151.camel@pelican.wigram> <874qp3mrdg.fsf@linux-france.org> <008201c45882$b3532560$19b0e152@warp> <525AEC07-C47B-11D8-A9FD-000393914EAA@atcorp.com> Content-Type: text/plain Message-Id: <1087931918.29427.23.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 23 Jun 2004 05:18:38 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 40D88625.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 38,:01 internals:01 reinventing:01 optimise:01 dependencies:01 re-writing:01 dependencies:01 9660:01 glebe:01 compiler:01 compilers:01 ocaml:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Wed, 2004-06-23 at 04:38, Eric Dahlman wrote: > The name for this process was "tree shaking" if ... camlshake .. is that a drink .. or a warning to hide under the nearest park bench and quiver in fear? > anyone is interested in looking into what was involved. The problem is well understood -- it's just garbage collection after all. The hard part is getting at the internals of the Ocaml compiler, so as to avoid reinventing the wheel in terms of parsing, lookup, etc but at the same time not reporting generated garbage (compilers often generate junk because it might be useful and optimise it away later). ---- Actually there is a modification of the original problem which is slightly more interesting theoretically: I personally often write: let rec f x = .. and g x = ... and h x = ... i.e. a huge chain of not necessarily mutually recursive functions at the top level. It would be interesting to see how one's scope control could be refined to make the actual dependencies more evident. I also often write: let f x = .. in let g x = .. in .. when there is no dependency -- it just looks cleaner than let f x = .. and g x = .. and .. in Obviously let[rec] [and] in can't express everything you want in terms of scope control, so I doubt there is an 'ideal' way to combine a set of functions .. which is what makes the problem of re-writing them to better express the dependencies interesting. [Of course there is a perfect solution using modules] -- 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