RE: [Caml-list] GODI (was: CTAN/CPAN for Caml (COCAN ...?))

[Gerd Stolpmann <info@gerd-stolpmann.de>]

Am Sam, 2003-07-19 um 22.40 schrieb BdB:
> Packaging and easing the distribution of libraries, is one issue ; naming
> hierarchy, i.e. ensuring non-collision of names used by different libraries,
> is another one. Both issues are very on-topic and need to be addressed. The
> only topic here is how to enable code reuse among the O'CaML community.

Both are related, at least in the sense that problems with code reuse
are often detected by packagers, or by users of packages. Furthermore,
packagers are the natural "authority" to ask the upstream developers to
change their software for better reuse.

> GS> Why don't you ask the developers to rename their modules?
> 
> I do not think it is very wise to "ask" too much -- especially such boring
> stuff as renaming -- in case of voluntary donations. Gerd, you are the
> author of findlib, which has been found out to collide with dynlink's Meta
> module, what did you think about having to rename all your modules to fl_*?

Given that I restructure my libraries from time to time from the grounds
up, this is really one of the things I try to take easy. Other types of
changes cause much more problems, especially inconveniences by the users
who have to follow the changes.

> Because you are an exceptionally generous contributor to the O'CaML
> community, you were willing to do this. But this raises the developer "entry
> barrier" significantly.

Yes, sure. But other "processes" do this, too, especially the namespace
approach you suggest.

> All the requirements I can come up with for now are listed below; I am
> curious to see what the list thinks about this. The numbers are just to keep
> track, not a rank.
> 
>  1. The top-level namespace should always be free to end-application
> developers
>  2. There should be syntactic sugar like "open" to access elements of the
> namespace in a context-sensitive manner -- some core namespaces should also
> be "open"-ed by default.
>  3. There should always be the option to use "fully qualified names" whose
> interpretation is immune to context variations. At any point in the code,
> all the namespace should be "locally accessible"; i.e. accessible by simply
> typing stuff where the cursor is, not needing to modify anything elsewhere.
>  4. It should be relatively painless for an application writer to spin off
> some top-level files of an application as a community library. This means it
> should be easy to move modules around in the namespace, or at least to push
> top-level modules down to other areas in the namespace.
>  5. The migration path for end-application developers should equally be easy
> (from the currently-flat namespace)
>  6. The SomeDataFormat example above must be able to be to be distributed in
> three parts situated at a hierarchical level below SomeDataFormat.
>  7. There should be room for
>     - Modules managed by the core language team (like the java.* namespace
> in Java)
>     - Managed community modules : CPAN-like archives
>     - Un-managed community modules : independent releases of libraries

That sounds really complicated! I am more and more thinking that we are
on the wrong track. Every hierarchical solution has the disadvantage
that it needs administration. I have an alternative, the "relational
solution". What we want to manage is nothing but a database of top-level
modules, and we want to find a way to uniquely identify every row of the
"modules table". Currently, the rows have only two fields: "name", and
"contents". My suggestion is to introduce further fields, like "author",
"organization", maybe even "version" and so on. So a module can have a
set of attributes:

module M = sig
  attributes
    author = "Gerd Stolpmann",
    organization = "ocaml-programming.de",
    version = "42.5"

  ... further signature ...
end

You can now disambiguate module names by these attributes, e.g.

open M[author="Gerd Stolpmann"]
open M[version>="42.0"]

To minimize the notation, I would suggest a default selection for the
whole module context:

select author="Gerd Stolpmann" for M
select organization="INRIA" | organization="..." | ... for *

The latter would be applied to all unqualified occurrences of top-level
module names, so you have typically only one extra line at the top of
every module implementation.

I would suppose this is very simple to implement in the compilers. There
is already meta data for top-level modules (the MD5 checksum), so it is
only an extension of this.

The best thing is that it is very natural for developers of libraries to
add the attributes to their exported modules. Collisions can be fixed
incrementally as they occur (even packagers could fix them easily
themselves). Maybe there could be a "style guide" explaining the
problems and how to address them by proper attributing the modules.

What do you think about this?

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------

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