Managing module names

Managing module names

[Paul Stodghill]

This is the message that I am going to send to Jason, Mark, and the Caml
mailing list. What do you think?

One of the things that modules in O'Caml can be used for is to prevent
namespace pollution. That is, functions and times encapsulated
within modules can be given names without fear that those names will
conflict with names in other modules.

But, how does one prevent pollution in the module namespace?

As near as I can tell, there are two ways to address this problem:

1) Carefully choose the names of the .ml and .mli files that will contain
   each of the top-level modules.

   E.g., Project_util, Project_expr, Project_toplevel

   The advantage of this approach is that each of these modules can go into
   its own source file and each can be compiled seperately. The
   disadvantage is that the module names tend to be longer, or less
   intuitive.

2) Enclose all of the "top-level" modules within a single "Project" module.

   E.g., Project.Util, Project.Expr, Project.Toplevel

   The advantage is that the names of the modules that are visible to the
   user of the Project module are more "rational", and the simpler names of
   the modules can be used simply by openning the Project module. The
   disadvantage seems to be that this requires some contortions in order to
   get this to work:

   Project.mli:
   module Util = Project_util
   module Expr = Project_expr
   module Toplevel = Project_toplevel

   Project_util.ml:
   (* implementation of the Project.Util module *)

   Project_expr.ml:
   (* implementation of Project.Expr module *)
   open Project_expr (* <- Yuck! *)
   ...

Here is my question: Are there other approach that people have used to
managing module name space pollution in O'Caml?

Thanks in advance.
-- 
Paul Stodghill <stodghil@cs.cornell.edu>
http://www.cs.cornell.edu/home/stodghil/home.html

Re: Managing module names

[David Monniaux]

[En Francais: pourquoi ne pas profiter du systeme de fichiers pour
rendre plus souple l'usage de la hierarchie de modules?]

Concerning the module namespace:
as far as I know, Java uses some mapping of the namespace onto the
filesystem, allowing easy filing of libraries.

Caml has a hierarchized modules system, but only allows toplevel
modules to be mapped into files.

Would it be possible to make up some scheme that would to things like:
/graphics/blackwhite/main -> Graphics.Blackwhite.Main ?

Or, better: would it be interesting according to other users?

-- 
David Monniaux, graduate student from ENS Lyon, France
Now at: Computer science laboratory  SRI International
        Formal methods group         Menlo Park, CA, US

Re: Managing module names

[Paul Stodghill]

>>>>> "monniaux" == David Monniaux <monniaux@csl.sri.com> writes:

    monniaux> [En Francais: pourquoi ne pas profiter du systeme de fichiers
    monniaux> pour rendre plus souple l'usage de la hierarchie de modules?]

Merci. :-) My French is, I am sorry to say, abhorrent.

    monniaux> Would it be possible to make up some scheme that would to
    monniaux> things like: /graphics/blackwhite/main ->
    monniaux> Graphics.Blackwhite.Main ?

    monniaux> Or, better: would it be interesting according to other users?

Absolutely! I think that such an arrangement would be even more useful
than what exists presently.

-- 
Paul Stodghill <stodghil@cs.cornell.edu>
http://www.cs.cornell.edu/home/stodghil/home.html

Re: Managing module names

[Judicael Courant]

[Version francaise ci-dessous]
>
>Concerning the module namespace:
>as far as I know, Java uses some mapping of the namespace onto the
>filesystem, allowing easy filing of libraries.
>
>Caml has a hierarchized modules system, but only allows toplevel
>modules to be mapped into files.
>
>Would it be possible to make up some scheme that would to things like:
>/graphics/blackwhite/main -> Graphics.Blackwhite.Main ?
>

I think there is a real problem for dealing with module namespace, but
I do not like this solution, because I may have a file
/graphics/blackwhite/debug.cmo that I do not always want to open. More
generally, I think that the interaction between the language and the
filesystem should be kept as small as possible.

Rather, I would prefer a small utility (let's say ocamllib) grouping
together a bunch of .cmo or .cmi files.

For instance assume a.ml contains

let x = 1

and b.ml contains

let x = A.x

then "ocamllib A.cmo B.cmo -o C.cmo" would give the same file C.cmo as
the compilation of the following C.ml :

module A =
  struct
    let x = 1
  end

module B =
  struct
    let x = A.x
  end

Of course, "ocamllib" should also apply in the same way to .cmi files.

There is then a clear distinction between the filesystem hierarchy and
the language constructs. And if you wish to, you could perfectly add
to your makefiles a rule such as

%.cmi: %
	ocamllib $*/*.cmi -o $*.cmi

IMHO, this mecanism would be a good replacement for the existing -a
option of ocamlc.

Also, I guess that implementing ocamllib is much simpler than
taking advantage of the filename hierarchy.


[English version above]
>
>[En Francais: pourquoi ne pas profiter du systeme de fichiers pour
>rendre plus souple l'usage de la hierarchie de modules?]

Il me semble que le besoin d'une gestion plus elabore de la hierarchie
des modules est reel, mais je preferais une autre solution, plus
independante du systeme de fichier.

On pourrait imaginer un utilitaire "ocamllib" capable de grouper des
.cmi ou des .cmo.

Ainsi, si a.ml contient

let x = "quel dommage que le francais ne soit pas la langue
internationale !"

et b.ml contient

let x = A.x

alors "ocamllib -o C.cmo A.cmo B.cmo" produirait un fichier C.cmo
identique a celui qu'aurait produit la compilation d'un fichier C.ml
contenant :

module A =
  struct
    let x = "quel dommage que le francais ne soit pas la langue
internationale !"
  end

module B =
  struct
    let x = A.x
  end


Mutatis mutandis pour les .cmi

De cette facon, on a une solution assez independante du systeme de
fichier employe, probablement plus efficace et plus simple a
implanter. Par ailleurs, rien n'empeche d'ecrire dans son Makefile une
ligne du type

%.cmi: %
	ocamllib $*/*.cmi -o $*.cmi


Judicael. 
-- 
Judicael.Courant@ens-lyon.fr, http://www.ens-lyon.fr/~jcourant/
tel : (+33) 04 72 72 85 82
<< Heureux ceux qui savent rire d'eux memes :
   Ils n'ont pas fini de s'amuser ! >>

Re: Managing module names

[Fabrice Le Fessant]

Bonjour,

  Pour ceux qui veulent utiliser un systeme de packages avec Ocaml
1.05, j'ai un patch du compilateur permettant de placer les modules
dans des packages. Cela evite les collisions de noms de modules
identiques lors du link. 

  Les noms des modules peuvent aussi etre allonges pour specifier le
package auquel ils appartiennent (toujours pour eviter une collision),
par la syntaxe <package>/module (par exemple, List devient
Stdlib/list). 

  Les packages ne correspondent pas a l'emplacement des fichiers, mais
a la facon dont les modules ont ete compiles:
ocamlc -c list.ml           ---> module List
ocamlc -c stdlib/list.ml    ---> module Stdlib/list
ocamlc -package stdlib -c list.ml ---> module Stdlib/list

  Cependant, le compilateur s'aide quand-meme des noms des packages
pour trouver les modules: Il cherchera d'abord un fichier
stdlib/list.cmi, puis un fichier list.cmi pour matcher le module
Stdlib/list.  

  Quand on ne specifie pas le nom du package d'un module, et que le
module trouve appartient a un package, le compilateur emet un Warning.

  Le patch avec plus de renseignements se trouve sur :
http://www-sor.inria.fr/~lefessan/src/

  

Re: Managing module names

[Frank Christoph]

> >>>>> "monniaux" == David Monniaux <monniaux@csl.sri.com> writes:
>     monniaux> Would it be possible to make up some scheme that would to
>     monniaux> things like: /graphics/blackwhite/main ->
>     monniaux> Graphics.Blackwhite.Main ?
> 
>     monniaux> Or, better: would it be interesting according to other users?
> 
> Absolutely! I think that such an arrangement would be even more useful
> than what exists presently.

In my experience, nested modules are not very useful in (O)CAML because you
cannot have a recursive definition cross a module boundary, and I find that
I quite often have mutual dependencies between sets of definitions whose
namespaces I would nevertheless like to separate.

I suspect that the reason package nesting in Java works so well is partly
due to the fact that recursion, etc. is hardly ever used.

On the other hand, SML seems to use module nesting quite freely, though,
and as far as I know it has the same restrictions on module dependencies...

-- FC