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