Date: Thu, 24 Jul 1997 16:36:54 +0200 (MET DST)
Message-Id: <199707241436.QAA02795@chianti.ens-lyon.fr>
From: Judicael Courant <Judicael.Courant@ens-lyon.fr>
To: monniaux@csl.sri.com
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 ! >>
This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:12 MET