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

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

Am Mit, 2003-07-23 um 11.35 schrieb Xavier Leroy:
> I have followed this discussion with interest, although other
> commitments prevented me from replying earlier.
> 
> I think there are two completely orthogonal issues:
> 
> 1- Caml library packaging: standardizing and automating the
> configuration, compilation, installation, dependency handling and
> re-compilation when dependents change.
> 
> 2- Name space management: avoiding the unfortunate situation where
> several packages define compilation units that have the same names.
> 
> I agree with Gerd that the first issue (library packaging) is by far
> the most acute.  The lack of a packaging framework currently makes
> using third-party Caml libs in a development much harder than it
> should be.
> 
> [...]
> That's why other cross-platform programming environments
> such as Perl and Python have developed their own packaging technology.

They did it also to demonstrate their usefulness in system
administration. I don't see that this is the natural application for a
universal language like O'Caml, so we could also reuse existing
packaging technologies provided they are portable enough. This is the
reason why I chose the NetBSD system for my experiments (which I have
actually done on Linux and Solaris, just to test the portability).
 
> Library packaging is one of those "soft", un-glamorous problems: there
> are no hard, open problems, just an endless series of small problems
> to be solved and policy decisions to be taken.  I had interesting
> discussions with several of you concerning possible designs, but
> apparently these efforts ran out of steam.  I'm very happy to see that
> Gerd (with his eminent practical sense) is giving it a try, and I wish
> he'd get more constructive feedback on this.

What I would like to hear is that:

- people are really interested in a source distribution
- people want to spend time and help packaging
- people want to contribute resources (e.g. network disk space)

The problem is that I have only very limited time for this, and I hope
that once the project is set up my assistance would not be needed any
longer.

> Now, the name space management issue seems over-inflated to me.
> Yes, it can happen, and may become a serious issue once we have
> hundreds of libs that need to coexist.  But I think we can still get
> a lot of mileage out of the current "global namespace for compilation
> units" model.  In particular, most libraries can be set up so that
> they define only *one* top-level module (i.e. compilation unit):
> 
> - put all sources in one file, possibly with sub-modules
>   (not as ugly as it sounds -- see my Cryptokit library for an example);
> - put all user-visible definitions in one file, say Mylib.ml, and 
>   put internal definitions in other files with unlikely names such as
>   MylibInternalFoo.ml, MylibInternalBar.ml, etc
> - use ocamlc -pack to assemble the library files into one compilation
>   unit.
> 
> Some people reject ocamlc -pack on the grounds that it prevents
> link-time elimination of unused sub-modules.  I think they are jumping
> to conclusions.  First, for many libraries, there is essentially no
> opportunity for this link-time elimination, as every sub-module is
> used.  Second, many libraries are small enough that the increase in
> code size doesn't matter much.  Third, this is a "quality of
> implementation" issue: I might be able to implement this link-time
> elimination for the native-code compiler (ocamlopt -pack) at some
> future time.  The problem remains for bytecode, though, but is perhaps
> less acute due to the small size of bytecode.

I think the real problem is that -pack is not supported on all
platforms, or only if you install GNU binutils. So up to now I have
understood -pack as an experiment.

> Finally, as this discussion demonstrates eloquently, there is no
> obviously good solution to the name space management problem.  Yes,
> various things can be done either at the language level or at the
> compiler level to support finer identification and re-naming of
> compilation units.  But I'd rather not settle on a half-baked solution
> to a non-acute problem.

Namespaces are not only a technical problem, but also a matter of good
organization. This is why almost every suggestion looks half-baked.
Furthermore, it was a bit surprising for me that most participants of
the discussion favoured hierarchical solutions, which would mean we need
some kind of "authority" administering the hierarchy. Very unlikely that
we ever get this, or can agree on it. (Don't forget that the Perl people
are often system administrators, and they are used to this kind of
management.) I really think that we should view namespaces as indexes to
an open, distributed database of modules (if this problem ever gets
acute), at least currently this would me more adequate to the grade of
organization of the O'Caml community.

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