caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: brogoff <brogoff@speakeasy.net>
To: caml-list@inria.fr
Subject: Re: [Caml-list] Circular module dependencies
Date: Tue, 7 Sep 2004 05:36:18 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.58.0409070524360.32038@shell2.speakeasy.net> (raw)
In-Reply-To: <20040907161253.2799ada5.ocaml-erikd@mega-nerd.com>

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


  reply	other threads:[~2004-09-07 12:36 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 [this message]
2004-09-07 13:39       ` Christopher A. Watford
2004-09-08  0:30       ` Erik de Castro Lopo
2004-09-07  6:14 ` Nicolas Cannasse

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=Pine.LNX.4.58.0409070524360.32038@shell2.speakeasy.net \
    --to=brogoff@speakeasy.net \
    --cc=caml-list@inria.fr \
    /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).