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] CTAN/CPAN for Caml (COCAN ...?)
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2003-07-22 (15:29)
From: Yamagata Yoriyuki <yoriyuki@m...>
Subject: Re: [Caml-list] GODI
From: "BdB" <bdbkun@wanadoo.fr>
Subject: RE: [Caml-list] GODI (was: CTAN/CPAN for Caml (COCAN ...?))
Date: Tue, 22 Jul 2003 02:01:45 +0200

> Any basis for disambiguation is to use meta-data. In the Java
> case, meta-data = package name = mono-dimensional hierarchical space. Gerd's
> proposal is, the meta-data can be multidimensional.
> I still think we should have at least the "primary key" of the meta-data to
> be structured hierarchically.

So we are going to define global identifies for modules.  Well, such a
move is neither necessary, nor sufficient for the conflict resolution,
unless the policy is strictly enforced, but then it has the own
drawback.  Global identification is certainly interesting facility,
but our problem (the conflict of the name space) raises well before
the problem of global identification.  Actually, we do not have the
method to manage the name space even locally.

I think we should tackle this problem by a step-by-step manner, like

    a) Make a tool consistently renaming the modules.  Also,
    modification of the compiler to "untie" the module name from the
    file name would be required.

    b) Incorporate these tools to package management tools.  For
    example, when installing a package, each module in the package is
    renamed to <package name>_<original module name>.  Also, we may
    need to add the "completion" facilities to the compiler, so that
    if <package name> is omitted, the compiler will automatically
    search the right module.

    c) Adopt hierarchical package names, say, Num_Matrix_<....> and
    enable users to "mount" these hierarchies to nodes they choose.  So,
    for example, some users choose stdlib resides the top level, while
    some users mount them under Stdlib... and so on.

I think many people have similar ideas.

Yamagata Yoriyuki

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