On 21-Oct-1998, S. Alexander Jacobson <[EMAIL PROTECTED]> wrote:
> This discussion seems to be mixing a few different issues. I believe any
> proposal here needs to satisfy three criteria:
>
> 1. it must allocate top level name space in a way that prevents collisions
Well, avoiding namespace collisions in general must certainly be a
prime objective of any module system. However, collisions at the top
level are in fact the rarest kind of collisions (just by virtue of the
fact that there are a lot more names at the bottom level), and they are
generally not much harder to fix than other kinds of collisions,
so this is not something which I would consider a necessity --
a desirable property, certainly, but IMHO not a necessity.
I'd prefer to state this as
1. it must aim to prevent name collisions, and where this is not
possible it should provide the programmer with a means to
resolve any name collisions that do occur
> 2. it must allow an implementation to resolve names to locations efficiently
... without being too difficult to implement.
> 3. it must give developers control over the visbility of their objects
Agreed.
> David says:
> > To be a bit more specific; it seems that we have this mechanism now.
> > [...]
> > 2) inter-package visibility provided by (possibly multiple) public
> > import-export (gather) modules that form the interface to the
> > entire package, where a gather module is defined as one that
> > contains no code, but a series of import statements and a re-export
> > list.
>
> But gather nodes do not prevent other programmers from importing
> implementation modules directly and bypassing the gather nodes.
> There should be some facility for specifying which modules of a package
> are publicly visible and which are purely for use by other modules within
> the package (or local cluster).
Yes.
In Mercury, we use module nesting rather than "gather" modules;
we nest the different modules inside a parent module, which specifies
which of them are private and which are public.
> However, I do agree with David that separating library issues from language
> issues is a good thing, I propose this library system:
>
> The implementations should have a make-library command that
>
> 1. takes as arguments
> * a library name
> * the names of the public gather nodes
> * access permissions for the library
> 2. uses import chasing to find the implementation modules
> 3. constructs a package (jar/tar/zip?) through which only the named
> modules are visible to other programmers (renames the other modules?)
Implementing 3 is difficult if you compile to native code (whether
directly or via C), and you want it to apply to libraries distributed
in precompiled binary format rather than as source code. In general
it requires architecture-specific complicated munging of the generated
library files (`.a', `.so', `.DLL', etc.).
--
Fergus Henderson <[EMAIL PROTECTED]> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED] | -- the last words of T. S. Garp.
