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 IAA10032; Tue, 7 Sep 2004 08:13:01 +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 IAA10907 for ; Tue, 7 Sep 2004 08:13:00 +0200 (MET DST) Received: from smtp-2.syd.swiftdsl.com.au (smtp-2.syd.swiftdsl.com.au [218.214.224.98]) by nez-perce.inria.fr (8.13.0/8.13.0) with SMTP id i876Cvw1016028 for ; Tue, 7 Sep 2004 08:12:59 +0200 Received: (qmail 31136 invoked from network); 7 Sep 2004 06:13:05 -0000 Received: from unknown (HELO coltrane.mega-nerd.net) (218.214.64.136) by smtp-2.syd.swiftdsl.com.au with SMTP; 7 Sep 2004 06:13:05 -0000 Received: from coltrane (localhost [127.0.0.1]) by coltrane.mega-nerd.net (Postfix) with SMTP id 03B567AE1 for ; Tue, 7 Sep 2004 16:12:53 +1000 (EST) Date: Tue, 7 Sep 2004 16:12:53 +1000 From: Erik de Castro Lopo To: caml-list@inria.fr Subject: Re: [Caml-list] Circular module dependencies Message-Id: <20040907161253.2799ada5.ocaml-erikd@mega-nerd.com> In-Reply-To: References: <200409070917.18022.edgin@slingshot.co.nz> Organization: Erik Conspiracy Secret Labs X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 413D5169.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 dependencies:01 2004:99 brogoff:01 brogoff:01 fergus:01 dependencies:01 refactor:01 hiearchy:01 charm:01 compiler:01 speakeasy:01 sep:01 modules:02 nospam:97 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Mon, 6 Sep 2004 21:39:21 -0700 (PDT) brogoff wrote: > In a discussion on this topic a while back, Fergus Henderson cited as an > example the Mercury compiler, where removing the dependencies by making one > big file of the dependent parts would lead to a pretty large file. I thought > that was a decent argument in favor of allowing mutually recursive functions > to cross module boundaries. I was the initiator of a discussion much like this just recently. The good advice I got was to refactor and move the common stuff own the module hiearchy. So if you have two modules A and B which SEEM to need each other, create a new module C containing the required commong code and use the functionality of C in both A and B. I tried this for my situation and it not only worked like a charm, in hindsight it made a whole lot more sense this way. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo nospam@mega-nerd.com (Yes it's valid) +-----------------------------------------------------------+ "Perl : this is a blue collar language" - Angus Lees ------------------- 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