[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Module system: A compromise idea.
Module system: A compromise idea.
Tue, 19 Dec 2000 11:37:59 +0100 (MET)
We have had an interesting discussion so far about the possibility to use
or not to use Dybvig's module system for guile. First, I'd like to state
that I did not intend my mails to have an offending tone. If it did so,
please accept my apologies.
I have to admit that Dybvig's system has a lot of nice properties. But,
as I have explained, if just taken as it is, it also offers good chances
to shoot oneself into the foot.
In any case, if we would like to use Dybvig's system, we still would have
to solve a couple of problems: Dybvig's system works on the scheme level.
We would still need to offer C level primitives for things like
referencing bindings in a module, creating bindings in a module, creating
export lists etc. Further, we would have to provide a means to pass
environments to eval. (Maybe this is just as easy as passing one of
Dybvig's modules to eval, but I have not thought closer about it.)
Finally, we want better support for interactive development and maybe even
being warned about things that might have 'surprising' consequences.
The problem is here, all benefits that we have on the scheme level (like
macro-expanding away anything that is module system) does not apply on the
So what about the following idea:
When implementing the module system (on C as well as scheme level) we
make sure that Dybvig's system would form a potential compilation
environment. In other words, we provide C and scheme level functions like
"module-ref" (which is called "from" by Dybvig), and make sure that they
would be implementable with the same semantics in Dybvig's system. Then,
when compiling code written for our module system, we could just plug-in
Dybvig's transformation system and replace anything that is a C level
primitive with the corresponding "Dybvig-macro".
With respect to Dybvig's low level primitives "module", "import" and
"import-only": IMO, we shouldn't offer these as primitives. When
plugging in Dybvig's transformer, those will be temporarily created
because of the macros that use them (like module-ref/from), but as Mikael
has explained, these will have disappeared after all macros were expanded.
In guile's system, however, only derived forms are provided. This would
remove my concern about the mis-use of "import" in local scopes.
For example, we could provide module-ref/from as a C level primitive that
does binding of non-macro objects lazily, i. e. whenver the code is
executed, the binding at that time will be read from the corresponding
module. Thus, intermediate changes to the module will become visible when
the code is executed afterwards. For compilation, module-ref/from will be
bound to a module such that it can be handled by Dybvig's transformers.
During compilation, we don't have to care about dynamic changes. Since
people will use compilation only for those parts of the code which they
consider finished, changes to such code will be comparably rare and it
will be acceptable if those parts have to be recompiled whenever something
A general problem is how to deal with changes to macros in the interactive
case. However, this is a problem that is not specific to whether we
are using Dybvig's system or not. Changes to macros require to
re-transform those expressions that had been using the old version of the
macro. But, this is (I assume) a less frequent case than just the
changing of other bindings.
With such a compromise, we would have a system that is compilable using
Dybvig's approach, but during interactive use we would only need to
recompile things if syntax bindings change, and not for _every_ change.
To realize the approach described here, we would have to provide two
implementations for every module system primitive: One implementation
that is based on Dybvig's module/import/import-only primitives, and one
implementation that performs reading from modules lazily and can be used
from the C level (and scheme level as long as being interactive).
This need to double-implement module system functionality may seem to be a
disadvantage, but if we want to be able to use the module system from the
C level, we would (for performance reasons) need a C implementation of
module system functions anyway. The good point is, if we take
implementability with Dybvig's system as an orientation point, we have the
additional possibility to implement the system in a way that is easily
compilable (and where a compiler already exists!).
- Module system: A compromise idea.,
Dirk Herrmann <=