caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: David Brown <caml-list@davidb.org>
To: Alessandro Baretta <alex@baretta.com>
Cc: Chris Hecker <checker@d6.com>, Ocaml <caml-list@inria.fr>
Subject: Re: [Caml-list] camlimages vs. labltk
Date: Thu, 27 Mar 2003 09:23:05 -0800	[thread overview]
Message-ID: <20030327172305.GA10977@opus.davidb.org> (raw)
In-Reply-To: <3E8216B0.2070206@baretta.com>

On Wed, Mar 26, 2003 at 10:08:00PM +0100, Alessandro Baretta wrote:

> Module encapsulation ? la -pack addresses a different issue. 
> Packing eliminates the name clashes by reducing the number 
> of distinct modules. A lot of small modules are packed into 
> one big one, and, voil?, the name clashes are gone. Yes, but 
> this is a side effect. The main effect is that you get one 
> big chunk of code which can no longer be refactored into its 
> individual components: problems arise whenever one of the 
> packed modules defines values which, upon definition, 
> immediately perform computations. Even functional values 
> could be defined in such a way as to engender a computation.

I think talking about namespaces is addressing the wrong problem.
Namespaces are merely a subset of the functionality already in the
module system.  They are usually put into languages that don't have good
module systems.

The -pack option is an attempt (in my impression a poor one) to solve a
different problem, easier separate compilation.  The functionality of
-pack could also be done (more difficulty) by choosing weird names
within the parent module, and having a single module encapsulate
everything.  I've seen code that does it this way.

If I get some spare time, I may try implementing the suggestion I gave
before, which I think is a nice elegant solution that doesn't change the
syntax or grammar of the language at all.  Here it is, boiled down:

Say for example, I want a large system Mylib, in it I want three
submodules: Mylib.Types, Mylib.Helper, Mylib.Process.  My proposal is to
have the following files:

   mylib.ml, mylib.mli  - might be empty if nothing is declared at the top.

   mylib-types.mli mylib-types.ml
   mylib-helper.mli mylib-helper.ml
   mylib-process.mli mylib-process.ml

When compiling other code, a reference to Mylib.Helper.foo will first
check for a mylib-helper.cmi, and then in mylib.cmi (in case the module
is defined there).

GHC (Haskell) does something similar to this.  To do it, some though
will have to be put into the exact semantics, this is just the general
idea.

Dave Brown

-------------------
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:[~2003-03-27 17:23 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-25 19:33 Shivkumar Chandrasekaran
2003-03-26  8:25 ` Alessandro Baretta
2003-03-26  8:33   ` Sven Luther
2003-03-26  9:00     ` Alessandro Baretta
2003-03-26 10:50       ` Sven Luther
2003-03-26 11:24         ` Alessandro Baretta
2003-03-26 11:38           ` Sven Luther
2003-03-26 19:08             ` Chris Hecker
2003-03-26 21:08               ` Alessandro Baretta
2003-03-27 17:23                 ` David Brown [this message]
2003-03-27 19:46                 ` Chris Hecker
2003-03-28  5:33                   ` Alessandro Baretta
2003-03-28  5:35                     ` David Brown
2003-03-28 14:10                   ` Damien Doligez
2003-03-28 15:00                     ` Sven Luther
2003-03-30 10:06                       ` Damien Doligez
2003-03-30 10:38                         ` Sven Luther
2003-04-01 14:14                           ` [Caml-list] naming conflicts (was: camlimages vs. labltk) Damien Doligez
2003-04-01 15:05                             ` Benjamin C. Pierce
2003-04-01 19:51                             ` Chris Hecker
2003-04-08 10:33                               ` Damien Doligez
2003-03-31  1:21                         ` [Caml-list] camlimages vs. labltk Chris Hecker
2003-03-30  9:26                     ` Alessandro Baretta
2003-03-26 18:49     ` Shivkumar Chandrasekaran
2003-03-26 10:48   ` Stefano Zacchiroli
2003-03-26 10:55     ` Sven Luther
2003-03-26 14:10       ` Stefano Zacchiroli

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=20030327172305.GA10977@opus.davidb.org \
    --to=caml-list@davidb.org \
    --cc=alex@baretta.com \
    --cc=caml-list@inria.fr \
    --cc=checker@d6.com \
    /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).