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

["BdB" <benoit.de-boursetty+caml-list@m4x.org>]

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.

One question I have about "-pack": say you want to distribute
SomeDataFormat.Parsing, SomeDataFormat.PrettyPrinting and that you want to
factor in-memory representations of data into SomeDataFormat.Common (this
situation almost always occurs for I/O modules). How do you do this
with -pack? How do you distribute these 3 modules to developers? Developer 1
wants to only parse so should have Parsing and Common, developer 2 wants to
only print so should have PrettyPrinting and Common, and developer 3 wants
to do both so should have them all... Wouldn't "-pack" enable you to only
distribute one big SomeDataFormat module?

If so, then as of now the "-pack" option can't be used to distribute library
modules. Another way is to use prefixed top-level names such as
SomeDataFormat_Parsing for modules -- like in C, which does not have any
form of namespace structure, but whose community respects a code of practice
that is to give prefixes to all exported functions.

I personally am not too keen on this. One major issue I have with this is
that when you decide to release some files that were used internally, you
have to add a prefix to your top-level files. Staying at the top-level
implies having to run sed through all your code (in the easiest case). I
guess the intent of "-pack" was to simplify this...

GS> I would say [namespace clash] is a minor problem [...].

This problem is not minor. It has shown up in the past repeatedly up to the
point that people can't solve it on their own and send an email to the
mailing list, which usually spawns a thread similar to this one. It will all
the more occur as the community scales up.

Here's a pick of some threads in this mailing list:

     * << I observed that both camlimages and labltk have a module named
"Image". >> @ http://caml.inria.fr/archives/200303/msg00345.html

     * Someone wrote a module named "array.ml" and realized later they
couldn't access the "standard" array module anymore. Someone proposed to
rename the standard library modules to Std.* so that they don't clobber the
developer's namespace @ http://caml.inria.fr/archives/200208/msg00432.html

     * Name clash between findlib and dynlink's "Meta" modules @
http://caml.inria.fr/archives/200209/msg00232.html

GS> I would say [that name clash is] not even a technical [problem].

True! I am not talking about a specific language feature, but about a
problem whose solution may involve a combination of standard community
practices, utilities, and language features. Just because it is not entirely
technical does not mean it is not important.

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_*?
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.

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

Finally, I came across this old post by Yurii A. Rashkovskii @
http://caml.inria.fr/archives/200211/msg00002.html . I don't know if there
have been any follow-ups to it, but it gives an example of namespace added
through preprocessing. Worth reading at any rate...

BdB.

> -----Message d'origine-----
> De : owner-caml-list@pauillac.inria.fr
> [mailto:owner-caml-list@pauillac.inria.fr]De la part de Gerd Stolpmann
> Envoyé : samedi 19 juillet 2003 14:39
> À : Fernando Alegre
> Cc : Shawn Wagner; caml-list@inria.fr
> Objet : Re: [Caml-list] GODI (was: CTAN/CPAN for Caml (COCAN ...?))
>
>
> Am Sam, 2003-07-19 um 14.18 schrieb Fernando Alegre:
> > I use Debian and I am happy, thank you very much, but that's good enough
> > for me. I guess RedHat/Suse/Mandrake users think similarly, and windows
> > users... get what they pay for, sorry.
>
> I.e. nothing. Debian is the only distribution with good O'Caml packages
> I know. From a common point of view this is a very unsatisfactory
> situation, because Debian is not the world.
>
> > Packaging is off-topic. The on-topic problem is module naming. If I want
> > to use two packages in my program, but both have a module called Stuff,
> > I have a problem. Current workarounds:
>
> I would say this is a minor problem, and not even a technical one. Why
> don't you ask the developers to rename their modules?
>
> > 1) Use -pack to wrap all package1 modules under Package1, and
> all package2
> >    modules under Package2. Problem: -pack uses a cmo instead of
> a cma. So,
> >    many unnecessary modules might be linked into my program.
> This affects
> >    compilation time and size, but it should not affect run time.
> >
> > 2) Manually rename some modules. Problem: Each time I upgrade, I have to
> >    do the renaming again. Time-consuming.
> >
> > The on-topic question is: Is there something better that the
> OCaml developers
> > could provide without taking them too much effort? User-only
> solutions are
> > not going to make it.
>
> Gerd

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