Re: A module system should resolve, not introduce, name conflicts

[Neil Jerram <neil at ossau dot uklinux dot net>]

Rambling thoughts about Jonathan Rees' module system...

The information described by the module configuration language can be
divided into two: (1) source-spec - specification of where the
module's underlying code comes from, (2) interface - specifies which
names from the module code get exported.  Note that (1) fundamentally
has to be described by a name in a globally accessible namespace
(otherwise how could arbitrary chunk of code X reference it?) which
cannot be the same as the module's internal namespace (otherwise you'd
have to read the module before you could read it...).  In Guile's
current module system, this global namespace is the file system.

(2) could live in the module's internal namespace, e.g.

    ... module implementation code ...

    (define *interface* '(export a b o ab))

since the module system could be implemented such that it only needs
to know the interface after it has evaluated the module code.  But it
could also live in a global namespace like (1).  (Or we could support
both, to allow module code to specify its own interface inline.)

I like the way that Rees' module system tries to let the underlying
module code stand on its own as a pure RnRS Scheme program.
Unfortunately, though, it doesn't really succeed.  The module code is
not, in general, self-contained, because it relies on imported names
from other modules that are specified by an (open ...) clause
elsewhere (in the module configuration).  This is a fundamental
problem: it will remain impossible for a modular Scheme program to be
both self-contained and pure RnRS, until RnRS includes something like
open, require or use-module.  In the meantime, I think that
self-containedness (for comprehensibility) is more important than
purity, so I would prefer to see "use-module" in the module code than
"open" in the module configuration.

Rees suggests, by the way he presents its grammar, that the module
configuration language is an independent language that just happens to
look quite like Scheme.  I think that the module configuration
language should in fact be Scheme, but with module configuration names
and without all the standard names.  (I may have completely
misinterpreted his presentation here!)

I don't understand the paragraph where Rees' says "The need to make
structures and interfaces second-class instead of first-class results
from the requirements of static program analysis: ..." (page 12).  Can
someone explain?

(What's the difference between (i) a "second-class object" and (ii) a
first-class object bound to a name in a namespace that is only
accessible through procedures like define-module, use-module,
list-modules, etc.?)

Inconclusively yours,

      Neil