English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

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: 2003-03-27 (17:23)
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.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

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