[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New module system
From: |
Mikael Djurfeldt |
Subject: |
Re: New module system |
Date: |
19 Dec 2000 18:39:18 +0100 |
User-agent: |
Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 |
Jim Blandy <address@hidden> writes:
> Mikael Djurfeldt <address@hidden> writes:
> > Jim Blandy <address@hidden> writes:
> > > What if the macro has expanded to a bunch of top-level definitions
> > > which have been evaluated?
> >
> > Answer: The macro call would be unexpanded.
>
> Leaving the definitions created by the old expansion still in the
> environment? That doesn't seem right. It certainly breaks the
> consistency rule I just made up a few minutes ago. :)
>
> I'm just saying that reloading one file may imply that others need to
> be reloaded too. What's wrong with that?
Was going to say "Nothing---that's an excellent idea.", but look
below...
> > Now, I've not turned into the Knight of the Macro Call Unexpansion
> > Crusade yet, but right now, the suggestion to add macro calls to the
> > unmemoization protocol seems to increase consistency in the system in
> > the sense that as soon as you have re-evaluated a macro definition,
> > all uses of that macro elsewhere will have a behaviour consistent with
> > the new definition.
>
> I agree, it increases consistency. But I bet a smart reload command
> would be more useful, more consistent, and simpler.
No, not "more" useful, but "also" useful.
I run Guile through Emacs. Typically, I make a change to a definition
and press C-M-x to send that individual definition over to Guile.
If this is definition of a macro, I still wouldn't like my pressing
C-M-x to cause reloading of a bunch of files---those files may contain
side-effects, and they might not even be in a consistent state.
Still, I *do* like it if all uses of my macro will from now on have
the new behaviour.
I was going to write "It's OK if the command to reload one module
might cause reloading of other modules." but then I realized that
those modules might not be in a consistent state. Maybe I'm working
on them right now? Hmm...
It seems like adhering to your consistency rule to 100% is more the
rolw of the development system into which Guile is embedded than the
role of Guile itself.
Probably, being consistent with a few simple, intuitive, rules is more
important than maintaining a 100% consistency in the entire system.
Such a rule could be: "A definition takes effect when you evaluate it."
What is wrong with automatic reloading of other modules is that they
can have side-effects and can be inconsistent. During development
the programmer has a need of some degree of control of what is being
loaded.
- Re: Macro uexpansion, (continued)
- Re: Macro uexpansion, Craig Brozefsky, 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, Jim Blandy, 2000/12/19
- Re: Macro uexpansion, Mikael Djurfeldt, 2000/12/19
- Re: Macro uexpansion, Mikael Djurfeldt, 2000/12/20
- Re: Macro uexpansion, Craig Brozefsky, 2000/12/20
- Re: Macro uexpansion, Mikael Djurfeldt, 2000/12/19
- Re: New module system, Jim Blandy, 2000/12/19
- Re: New module system,
Mikael Djurfeldt <=
- Re: New module system, Marius Vollmer, 2000/12/19
- Unmemoization of macros, Mikael Djurfeldt, 2000/12/19
- Re: Unmemoization of macros, Mikael Djurfeldt, 2000/12/20
- Re: Unmemoization of macros, Marius Vollmer, 2000/12/23