[Top][All Lists]

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

Re: New module system

From: Marius Vollmer
Subject: Re: New module system
Date: 20 Dec 2000 02:27:56 +0100
User-agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7

Jim Blandy <address@hidden> writes:

> I think it's terribly important to maintain consistency --- that the
> state of the system after you've done a series of arbitrary module
> changes and reloads is the same as if you'd loaded the whole shebang
> afresh.  Otherwise we're just planting time bombs.

There is much left to be defined more precisely before we know what
`maintaining consistency' means and before this requirement can be
implemented satisfactorily, I think.

For once, I don't really know if I understand you right, Jim.  Are you
arguing pro or contra automatic macro-re-expansion here?

I can see two lines of argumentation.  The first: when a macro
definition changes, all source code that uses that macro needs to be
recompiled, because the system as a whole needs to be brought uptodate
(automatically, silently, efficiently) as if the redefinition never
took place and the new definition was the original one.

This is a static view of the system, or `declarative'.  The desired
state of the system is defined by compiling everything from its
sources when anything changes.  We might take shortcuts, if we can
prove that they are safe.

The other: when a macro definition is changed, nothing happens,
because there are no dormant `uses' of a macro out there at all,
because a macro is only used during compilation, and compilation is an
(explicit or implicit) user action.  The system is consistent because
it is part of the definition of how the system behaves that it matters
when macros are expanded and that later changes to the macro
definition only affect newly compiled code.  Reloading a module might
or might not recompile it, but the use is expected to know what will

This is a dynamic view of the system, or `operational'.  The desired
state of the system is defined by the sequence of actions that have
been performed and the results of those actions are predictable.

I think that the `static' and the `dynamic' view of the system are
hard to reconcile.

I also think that static consistency is an ideal that is not
attainable in an interactive system.  Assume we don't have any macro
machinery and no compilation in the system, all we have is a simple
interpreter right out of some textbook.  I'd say that even in such a
system, we can't get full static consistency.  The static view does
not take the acquired state of the system into account when enforcing

Just think about top-level procedures that have ended up in some table
during the course of the program and then you redefine one of the
top-level procedures.  What should happen to the procedures in the
table?  Schould they be updated as well?  How?  Is that what we want,

I find these kind of questions very hard, even impossible to answer
once and for everyone in confident manner.  And I'm afraid that these
questions pop up in every corner that we try to make statically
consistent.  Thus, I'm very much in favor of the dynamic view of
consistency for interactive systems.  Keep the reactions of the system
simple, and people will be able to understand them and work with them.
If a macro changes, it is easy to understand that this doesn't affect
already compiled code, and it also reasonable to expect the user to
initiate a recompile, if he so desires.

I think we should have a interactive system (because that is one of
the big advantages of Lisp environments) and I'd say that we shouldn't
try to maintain static consistency in it.  I'm afraid that--in the
context of Guile--it will distract us from more important goals and it
might just be a failure in the end because people don't want it
because it's too `magical'.

reply via email to

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