Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] camlimages vs. labltk
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: David Brown <caml-list@d...>
Subject: Re: [Caml-list] camlimages vs. labltk
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.mli  - might be empty if nothing is declared at the top.


When compiling other code, a reference to 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

Dave Brown

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: