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

[Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>]

Silly enough I haven't read the paper yet (well, I did a few years
ago).  So, these comments should be taken somewhat preliminary.

Also, I'm not proposing that we copy Rees's system verbatim.  But it's
surely worth a good look at.

Neil Jerram <neil@ossau.uklinux.net> writes:

> (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.)

It's a strength of Rees's system that the module's name space isn't
clobbered.

Also, it seems natural that the name space of interfaces is the same
as the name space of structures.  This name space should probably be
similar to the name space of a module, although hierarchical, and it
is partially mirrored by the file system.

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

Firstly, having a clean name space is not only pure, but practical as
well.  It is not a good idea to grab a name like `use-module' for
talking about things which are on a meta-level relative to the other
names in the module.  You might want to use this name in the module
level.  Note what happened to the guy trying to use `unit' in
MzScheme...

Secondly, it is certainly impossible to invent a sensible module
system which allows for self-contained R5RS Scheme programs in the
first sense above, but this is not what Rees's system intends to do.
The important thing is that the program code can be pure R5RS.  I also
don't understand how relying on `use-module' is more self-contained
than relying on the configuration language.  To me, the only
difference is that Rees's system makes a clean separation between two
fundamentally different levels.

> 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!)

Could you please clarify [look, spelled correctly! 8-)] this?  It
seems to me that a language is defined by its grammar, so since the
grammar of the configuration language is different from the grammar of
Scheme, it is not Scheme.  However, it is an extension of Scheme,
since <program> is the root non-terminal in the Scheme grammar.

What is "module configuration names"?

Best regards,
/mdj