Version française
Home     About     Download     Resources     Contact us    
Browse thread
Managing module names
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Judicael Courant <Judicael.Courant@e...>
Subject: Re: Managing module names

[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 ! >>