Re: New module system

[Dirk Herrmann]

On 18 Dec 2000, Mikael Djurfeldt wrote:

> Dirk Herrmann <address@hidden> writes:
> 
> > (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.
> 
> I question that we would like this.  Look at the following code:
> 
> (use-modules (A) (B))
> 
> (let ((u v))
>   ...E...)
> 
> To me, saying that we would like a definition of y in M to have an
> immediate effect on the code seems comparable to saying that we would
> like u to change value in the lexical environment if A ceases to
> export v and B starts to export a different v...
> 
> We have accepted that once the lexical environment E above has been
> formed, it is immutable.  Similarly, it seems reasonable that the
> syntactic bindings exported by M only have effect when the code is
> expanded.

Hmmm.  I think I was not explicit enough in my previous mail:

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

We want modules in order to allow separate development of code.  The
developer of module M might decide to change M such that a newer version
would export a binding for 'y.  With Dybvig's system, this is extremely
dangerous, since all code that made use of M would break if that code used
a local variable 'y, because due to the change to M, bindings to local
variables would be changed.

This is completely independent of whether M is changed interactively or
not.

Best regards,
Dirk Herrmann