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

[Xavier Leroy <xavier.leroy@inria.fr>]

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.

Someone objected that this isn't a Caml-specific issue and that it can
be handled by standard packaging tools.  Perhaps, but the problem is
that there are no standard packaging tools.  Even among Linux
distributions, the packaging tools vary widely.  Not to mention other
Unixes (BSD, Solaris, Tru64, ...), and MS Windows.  This flies in the
face of the cross-platform portability offered by the core Caml
system.  It's not reasonable to expect that the world will convert
overnight to Debian's "apt".  It's not reasonable either to expect
library writers to package their libs for 8 different packaging
systems, especially when most of them wouldn't touch Windows with a pole.
That's why other cross-platform programming environments
such as Perl and Python have developed their own packaging technology.

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.

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.

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.

- Xavier Leroy

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