guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dybvig's module system and interactivity


From: Dirk Herrmann
Subject: Re: Dybvig's module system and interactivity
Date: Mon, 18 Dec 2000 19:05:52 +0100 (MET)

On Mon, 18 Dec 2000, Mikael Djurfeldt wrote:

> I think it's nice to be able to "walk around" among modules, make
> modifications etc. during development.
> 
> Maybe it's possible to modify Dybvig's implementation so that, instead
> of using one top-level environment, we place top-level bindings in
> separate modules, but let the expander expand references directly into
> glocs, thereby bypassing module borders?

My position on Dybvig's module system is:  We should not use it.  Maybe
we can figure out something that removes its problems, but at least
now I don't see any solution.  I will try to give a better explanation of
what I think are the problems with that system.

Dybvigs module system is based on the "import" primitive.  This primitive
accepts one module as parameter and will add all exported bindings from
that module into the current _local_ environment, thereby potentially
shadowing other bindings.

Let's assume the following code:

 1: (let ((x foo))
 2:   (import M)
 3:   x)

The value x in line 3 might refer to x in line 1, but if M exports a
binding to x, that binding will take precedence.  In other words, without
knowing the exact set of bindings that are exported by M, it is not clear
from that code, to what x refers.  Thus, Dybvig requires that the set of
exported bindings must be known at the time when the above code is
compiled.

I don't know what others think, but I would not want to have to check the
list of exports every time I import a module.  Further, I would not want
to do it again when I receive a new version of some module:  If the
implementor of M thinks that adding a binding for x in the next version 
of M is a good idea, this will break my code.  Worse:  It will break
silently, since the code is syntactically correct before and after that
change to M.

It is stated as a big benefit of Dybvig's system that it can be easily
compiled, because the code (or rather: the set of exported bindings) of
the modules and the code of exported macros are known.  But this is not
surprising:  _Any_ system that imports other modules could make use of
that knowledge.  It is IMO a big disadvantage that Dybvig's system
requires to see the module code, just to get the bindings even in local
scopes right, and even if the imported module does not define a single
macro.

OK, so if using import within a local scope is a bad thing, why not just
restrict its use to the top-level?  Sure, you could do that.  However, in
this case all the examples from Dybvig's paper (the implementation of
"from", "define-alias", ...) have to be implemented differently, because
their implementation depends on using "import" in a local scope.  In other
words, we would have to implement all interesting primitives for module
handling as if we would be starting to write a new module system on our
own anyway.


My aplogies if I am re-stating things that were already clear from my
previous mails.  But, I just don't see that Dybvig's system is _the_
module system we have been waiting for.  Sorry :-(

Best regards,
Dirk Herrmann




reply via email to

[Prev in Thread] Current Thread [Next in Thread]