[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New module system
From: |
Dirk Herrmann |
Subject: |
Re: New module system |
Date: |
Mon, 18 Dec 2000 15:14:06 +0100 (MET) |
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
Re: New module system, Mikael Djurfeldt, 2000/12/18
Re: New module system, Jim Blandy, 2000/12/18
Re: New module system, Mikael Djurfeldt, 2000/12/18
Re: New module system, Jim Blandy, 2000/12/19
Re: New module system, Mikael Djurfeldt, 2000/12/19
Macro uexpansion, Mikael Djurfeldt, 2000/12/19
Re: Macro uexpansion, Mikael Djurfeldt, 2000/12/19
Re: Macro uexpansion, Craig Brozefsky, 2000/12/19
Re: Macro uexpansion, Mikael Djurfeldt, 2000/12/19
Re: Macro uexpansion, Craig Brozefsky, 2000/12/19