Browse thread
[Caml-list] Circular module dependencies
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | brogoff <brogoff@s...> |
| Subject: | Re: [Caml-list] Circular module dependencies |
On Tue, 7 Sep 2004, Erik de Castro Lopo wrote: > On Mon, 6 Sep 2004 21:39:21 -0700 (PDT) > brogoff <brogoff@speakeasy.net> 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