> > Note that dynlink.cma not only contains Meta, but also other modules
> > with plain names: Misc, Config, Ident, Path, Types, i.e. names for
> > which name clashes are much more likely than for cryptic names.
> 
> Well, is it not for exactly this kind of problems that the -pack option
> was implemented ?

Yes, exactly.

> Would it not solve all this kind of problem if it
> would be a standard that all libraries should be using the -pack option
> for including their modules, thus having a Dynlink.Meta, Dynlink.Misc,
> Dynlink.Config, ... (and also i guess findlib would then have a
> Findlib.Meta or something such ?).
> Sure this would cause a bit of backward compatibility, but nothing that
> could not be solved by a simple open at the begining of the sources, and
> it would also most probably help solving much of the 'namespace'
> discution that happens here from time to time.

In the case of Dynlink, it's even better than this: the Misc, Meta,
etc, compiler modules that it imports are used purely internally and
need not be re-exported to the user, so we can keep the old API by
having just two modules, Dynlink (the user-visible API) and
Dynlink_internal_impossibly_long_name (a "pack" of the compiler
modules that Dynlink needs).

For other existing libraries, backward compatibility can deter using
-pack, but I'd encourage authors of new libraries to use it in order
to export only one compilation unit.

- 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