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

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

Mikael writes:

   Also, I'm not proposing that we copy Rees's system verbatim.

Quite.

   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.

I agree; I was just considering possibilities.

   This name space should probably be
   similar to the name space of a module, although hierarchical,

Yes, I think that both structures and interfaces need hierarchical
namespaces (in the same way, and for the same reasons, as, say,
classes and interfaces in Java).  E.g.

      (define-interface '(guile library db) '(export a b cons))

   and it is partially mirrored by the file system.

This would be natural, but I don't think it's necessary.

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

Good arguments, and I now agree with you.  The clincher for me
(implied by your arguments but not explicitly stated) is that the R5RS
code then becomes completely portable between different module
systems.

For example

      (define-class <my-class> ...)

is portable to any system which can provide a define-class with the
expected semantics - *which is what the application code needs* -
whereas

      (use-module (oop goops))
      (define-class <my-class> ...)

although perhaps easier for Guilers, also requires the use-module
name, which is spurious from the point of view of application
requirements.

In fact, the idea of the module configuration language could be
extended and recast as "the repository for all possible non-RnRS
meta-information".  As well as the info specified by Rees's module
system, this could include

      - interface/structure documentation

      - name documentation

      - compilation hints

      - declarations to specify/restrict the valid argument types for
        exported procedures.

   > 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 I was trying to say here was

1. If it isn't Scheme, I find it confusing for it to *look* like
   Scheme.

2. If it is Scheme, then I think that structures and interfaces should
   be first class objects with the full machinery of Scheme available
   to compute their contents.

I think I now understand (from Jost's reply) why 2 is undesirable: it
would be too hard (or perhaps impossible) for a compiler to work out
and optimize what's going on.  And I'm not sure that 1 bothers me so
much any more either; in fact the parenthesized Scheme-style notation
is very clear for many purposes.

   What is "module configuration names"?

define-interface, define-structure, open, etc.

Regards,

        Neil