Re: New module system

[Mikael Djurfeldt]

Dirk Herrmann <address@hidden> writes:

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

I think you bring up an important point.

However, it might not be as bad as you describe it above.  Note that
Dybvig's system is entirely at the syntactic level.  It requires no
special support in the evaluator since the syntactic forms of the
module system will be expanded away when the evaluator starts building
lexical environments.

One strong point about this is that code written in that system can be
compiled to efficient code regardless of what involved constructs is
built using the system.

The basic problem you are addressing is essentially what to do with
already expanded code when a macro definition is changed.  Should we
or should we not re-expand code using the new definition?

I've never seen a system which re-expands code, but maybe this is
possible?  If we don't, and use Dybvig's implementation verbatim, the
effect will be that changes to one module won't affect other modules
which import from it until they are reloaded.

I need to think more about this.  Maybe the effect is actually good.
It removed a lot of complex issues and might make the system behave in
a more clean way.  On the other hand, maybe we indeed want more
interactivity.  And maybe there is a way to provide it.

/mdj

P.S. I'll answer your previous letter about the module API later.