From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id SAA02812 for caml-red; Thu, 11 Jan 2001 18:38:23 +0100 (MET) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id NAA12725 for ; Thu, 11 Jan 2001 13:50:02 +0100 (MET) Received: from mrwall.kal.com (mrwall.kal.com [194.193.14.236]) by concorde.inria.fr (8.11.1/8.10.0) with SMTP id f0BCo1j18498; Thu, 11 Jan 2001 13:50:01 +0100 (MET) Received: from mrwall.kal.com [194.193.14.236] (HELO localhost) by mrwall.kal.com (AltaVista Mail V2.0J/2.0J BL25J listener) id 0000_0045_3a5d_ac67_aec5; Thu, 11 Jan 2001 12:51:51 +0000 Received: from somewhere by smtpxd Message-ID: <3145774E67D8D111BE6E00C0DF418B663AD71D@nt.kal.com> From: Dave Berry To: gerd@gerd-stolpmann.de, Dave Berry , Xavier Leroy , Charles Martin Cc: caml-list@inria.fr Subject: RE: Module hierarchies Date: Thu, 11 Jan 2001 12:53:45 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain; charset="iso-8859-1" Sender: weis@pauillac.inria.fr The namespace aspect is not so straightforward when you have parameterised modules. Suppose we adopted a Java-like global namespace, with subspaces for each organisation, then for each project, etc. What would it mean to parameterise a namespace on another? You don't necessarily want an entry in the namespace hierarchy to refer to a complete semantic entity, but of course this is at the heart of ML module systems. Dave. -----Original Message----- From: Gerd Stolpmann [mailto:gerd@gerd-stolpmann.de] Sent: Wednesday, January 10, 2001 20:12 To: Dave Berry; Xavier Leroy; Charles Martin Cc: caml-list@inria.fr Subject: RE: Module hierarchies Your example shows that there are several aspects: - How to statically refer to a module at compile time = namespace aspect - How to separate the code base into separately linkable/loadable parts = library aspect - How to use/initialize the code, i.e. there may be fragments of libraries which can be used independently of the rest of the library In O'Caml, we have currently: - A library (always in archive format) consists of several toplevel modules - When linking the executable, only the actually referred modules of the libraries are included and initialized It is very simple to use libraries, but it might be difficult to produce them, because unfortunately the toplevel modules of the library are the compilation units when the library is created. For example, if I want to make a library with, say, IO.File, IO.Net, and IO.Base, I have only one compilation unit IO, although it is desirable to have thee such units which are linked together later. >[...] >So, how should this be packaged, and how should it be referenced? You don't >necessarily want to distribute the library as a single DLL, because you >might want to use only some parts of it. But you still want a nested >namespace. So it's a bad idea to require that a namespace refers to a >single compiled object. This is effectively what SML does -- a namespace >is a structure, and if one part of a structure is available then all parts >are (although an implementation might do something clever with delayed >loading). DLLs are more problematic than static libraries when only parts of the libraries are referred to, because it is more difficult to initialize a DLL only partly. (But I can still deliver the library as single DLL if the operating system has a mechanism that loads only the needed parts.) >You do want some way of distributing the library as a small number of files. >Distributing large numbers of object files is a pain, especially if they >have to be uninstalled in certain places. Archive files (ar, jar) are one >solution. You might also have a library that you want to distribute as a >DLL. > >Then you need to express dependencies. I think it's useful to be able to do >this at the library level -- e.g. to say that application A depends on >Basis.IO, and application B depends on Basis.* . You don't want to have to >list each file separately. Possibly this can be done by command-line >arguments, e.g. compile -I Basis\IO ? This is what I implemented in findlib, my package manager for O'Caml. It focuses on the delivery problems of libraries: Where is the library installed? Which archives belong to a library? Which dependencies exist? However, findlib is restricted because it only manages the details of the command line arguments of the O'Caml compiler. So it can't find out namespace conflicts, nor it can rearrange namespaces. The findlib URL: http://www.ocaml-programming.de/packages/documentation/findlib/ >So there are lots of issues to consider. At Harlequin we wrote several >project management systems for MLWorks, and a couple more for Dylan. They >all involved difficult design decisions. My current belief is that you >need a separate notion of library, being a namespace that corresponds to a >deliverable, with some notion of dependencies at the library level, as well >as dependencies between the modules in a library. I think that namespaces and libraries are simply independent notions. The current O'Caml implementation does this right when libraries are used; i.e. you can form a library from arbitrary modules. What is missing is the possibility to reorganize namespaces when libraries are created. Of course, DLLs are missing, too. Gerd -- ---------------------------------------------------------------------------- Gerd Stolpmann Telefon: +49 6151 997705 (privat) Viktoriastr. 100 64293 Darmstadt EMail: gerd@gerd-stolpmann.de Germany ----------------------------------------------------------------------------