caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Nicolas Cannasse" <warplayer@free.fr>
To: <edgin@slingshot.co.nz>, <caml-list@inria.fr>
Subject: Re: [Caml-list] Circular module dependencies
Date: Tue, 7 Sep 2004 08:14:24 +0200	[thread overview]
Message-ID: <003101c494a1$ecb2c1c0$19b0e152@warp> (raw)
In-Reply-To: <200409070917.18022.edgin@slingshot.co.nz>

> 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


      parent reply	other threads:[~2004-09-07  6:13 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-07  9:17 Tony Edgin
2004-09-07  2:28 ` Jacques GARRIGUE
2004-09-07 17:10   ` Christopher Dutchyn
2004-09-07  4:39 ` brogoff
2004-09-07  6:12   ` Erik de Castro Lopo
2004-09-07 12:36     ` brogoff
2004-09-07 13:39       ` Christopher A. Watford
2004-09-08  0:30       ` Erik de Castro Lopo
2004-09-07  6:14 ` Nicolas Cannasse [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='003101c494a1$ecb2c1c0$19b0e152@warp' \
    --to=warplayer@free.fr \
    --cc=caml-list@inria.fr \
    --cc=edgin@slingshot.co.nz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).