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 IAA13899; Tue, 7 Sep 2004 08:13:20 +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 IAA12431 for ; Tue, 7 Sep 2004 08:13:19 +0200 (MET DST) X-SPAM-Warning: Sending machine is listed in blackholes.five-ten-sg.com Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id i876DJHs006600 for ; Tue, 7 Sep 2004 08:13:19 +0200 Received: from warp (chateaudeau-4-82-225-176-25.fbx.proxad.net [82.225.176.25]) by postfix3-1.free.fr (Postfix) with SMTP id 3FE74173827; Tue, 7 Sep 2004 08:13:18 +0200 (CEST) Message-ID: <003101c494a1$ecb2c1c0$19b0e152@warp> From: "Nicolas Cannasse" To: , References: <200409070917.18022.edgin@slingshot.co.nz> Subject: Re: [Caml-list] Circular module dependencies Date: Tue, 7 Sep 2004 08:14:24 +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 413D517F.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 dependencies:01 dependencies:01 cyclic:01 interacts:01 semantically:01 encapsulate:01 brittle:01 cyclic:01 subtyping:01 recursion:01 cannasse:01 ocaml:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > Recently, there was a thread which talked about how difficult module > dependencies were to resolve for linking in Ocaml. I'm guessing this is > because of cycles in the dependency graph. > > My thought is that maybe Ocaml shouldn't allow this to happen. Wouldn't > cyclical module dependencies be a symptom of bad design? If a cyclic > dependency occurs I can think of two ways of removing. > > First, if the dependency is among modules which are closely related, the code > in each module in the cycle which interacts, should be extracted into its own > module. The cycle indicates code which is semantically related and would > probably be easier to understand if it were all contained in the same file > anyway. > > Second, if the cycle contains modules which aren't closely related, a new > module should be created to encapsulate this dependency. This could be done > using the Bridge pattern. Since mutual dependencies make code brittle, > explicitly revealing the cycle in a module makes the cycle more visible to > the programmers and thus easier to deal with safely. > > Are there any examples of cyclic dependencies which shouldn't be handled by > either of these cases? The theoric aspect of this approach are correct. However in practice you end up sometimes with very big modules that you would like to split into several files for the maintenance sake. This is very difficult to do since you have to analyse the non-recursive parts of your module, and you can't really split it in a logical way because you have to care about the specific implementation you made which could create a cycle. Think for instance someone programming in OO, where objects are naturally recursive (structural subtyping helps to break cycles here, but some can still remains). However in functionnal style this happen rarely, but is still IMHO a needed feature, the possibility of having such following wrong recursion being more rare and possible to detect at linking time : --- module A let x = A.x --- module B let x = B.x 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