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 OAA25941; Tue, 7 Sep 2004 14:36:24 +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 OAA26578 for ; Tue, 7 Sep 2004 14:36:22 +0200 (MET DST) Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id i87CaJUs023177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 7 Sep 2004 14:36:21 +0200 Received: (qmail 13405 invoked from network); 7 Sep 2004 12:36:19 -0000 Received: from shell2.speakeasy.net ([69.17.110.71]) (envelope-sender ) by mail2.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 7 Sep 2004 12:36:19 -0000 Date: Tue, 7 Sep 2004 05:36:18 -0700 (PDT) From: brogoff To: caml-list@inria.fr Subject: Re: [Caml-list] Circular module dependencies In-Reply-To: <20040907161253.2799ada5.ocaml-erikd@mega-nerd.com> Message-ID: References: <200409070917.18022.edgin@slingshot.co.nz> <20040907161253.2799ada5.ocaml-erikd@mega-nerd.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Miltered: at concorde with ID 413DAB43.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; brogoff:01 brogoff:01 caml-list:01 dependencies:01 2004:99 fergus:01 dependencies:01 refactor:01 hiearchy:01 charm:01 compiler:01 implementors:01 speakeasy:01 speakeasy:01 gnat:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Tue, 7 Sep 2004, Erik de Castro Lopo wrote: > 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. Over two decades of experience with Ada (a different language, sure, but similar enough for the purpose of this discussion) lead to the conclusion that being able to spread types across modules (more than what the Mercury implementors desired!) was desirable enough to be included in the language. I haven't followed Ada 200X for a while, but that was practically at the top of the change list last time I did, and GNAT even had an experimental extension to support it. In general, I agree that this can be a design error, but refactorings that are reasonable for toy code posted during an internet email discussion may not make sense when we're talking about files that are tens of thousands of lines long even in very high level languages. Scale changes everything. -- Brian ------------------- 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