Re: New module system

[Mikael Djurfeldt]

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.