Re: New module system

[Dirk Herrmann]

On Sun, 17 Dec 2000, Mikael Djurfeldt wrote:

> Given the limited resources we have to conduct the research, design
> and development that would be required to develop a good module system
> of our own, and given the excellent quality of Dybvig's new module
> system, I propose that we simply take Dybvig's system and adopt it for
> Guile:
> 
>   http://www.cs.indiana.edu/~dyb/papers/popl99.ps.gz
> 
> We would probably make a few extensions, though.  One such extension
> is that we'd like to handle hierarchical module names which can be
> mapped onto a corresponding file hierarchy, the way we do now.
> 
> Probably, the nicest way to do this is to define a new set of syntax
> handling Guile modules and write these macros in the language provided
> by Dybvig's system.
> 
> While Dybvig's system has many arguments speaking for it as a
> candidate module system for Guile (e.g. that it mixes very well with
> the syntax-case macros), the most controversial point is that it might
> turn out that the best way to implement it requires using information
> from previously compiled modules when expanding a new module.

I think the most controversial point is, that Dybvig's system is not about
top-level environments.  The following example is from the paper:

(let ((x 1))
  (module M (x setter)
    (define-syntax x (identifier-syntax z))
    (define setter (lambda (x) (set! z x)))
    (define z 5))
  (let ((y x) (z 0))
    (import M)
    (setter 3)
    (list x y z)))
--> (3 1 0)

The import instruction can appear anywhere within code and influences the
_local_ environment, not just the set of top-level bindings.  Thus, the
result is (3 1 0) and not (1 1 0):  The binding of x is changed by the
import command.

Thus, the system that Dybvig proposes requires changes to the evaluator
and the way that local environments are created.  An implementation
possibility was, that with every 'import' form a new element is pushed on
the stack of environment frames, but that's just a first thought and may
have problems.

To implement Dybvig's module system in an interactive environment as
guile's will lead to a couple of problems:  In the example above, we would
like to be able to define 'y' in module M, even after M was imported
somewhere.  However, after 'y' is defined in M, suddenly the semantics of
the command (list x y z) changes, because now y is taken from M and no
longer from the local scope.

IMO, this is a flaw in the system in general:  The semantics of the
example code above is completely dependent on the set of identifiers that
is provided by M.  Changes to M can have fatal consequences on code that
imports M, even in a compiled environment.  In other words:  You rather
don't use import, but only one of the derived forms (like 'from').

Best regards,
Dirk Herrmann