[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Unmemoization of macros
From: |
Marius Vollmer |
Subject: |
Re: Unmemoization of macros |
Date: |
23 Dec 2000 17:08:56 +0100 |
User-agent: |
Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 |
Mikael Djurfeldt <address@hidden> writes:
> I don't think there are any natural actions. I think we have
> multiple choices. I think the important goal is that the user can
> form a mental model of the system which is workable, not too
> complex, and that the system is consistent with this model, so that
> he can predict how the system will behave. I think this last thing
> about being able to predict is most important.
Yes, exactly my view of the situation. The two extreme points in my
description are not the only admissable positions, there is a whole
continuum inbetween. The pure static view might be too idealistic to
attain, and the poor dynamic view is too inconvenient. We need to
find a compromise somewhere. When in doubt, I tend towards the
dynamic side, because I think the semantics are easier to specify,
implement and understand in that direction.
Where to draw the line? I also thought about the instance updating
protocol, and I have to agree that it is very desirable to have such a
thing. It is relatively easy and concisely to specify, there already
exists mature real world implementations out there that have proven
themselves, etc.
But about macro unexpansion, I feel uneasier. I have never seen such
a thing in action (which only speaks about my ignorance). I expect it
to be hard to detect when a macro definition has actually changed when
you allow the transformer to run arbitrary code and call arbitrary
functions (which I think is highly desirable).
I'm not going to try to stop anyone from implementing a macro
unexpansion facility into Guile. But I have the feeling that we have
the tendency to pile feature on top of feature that we want Guile to
have, but not really getting anywhere. I think we should stay deeply
rooted in the `existing art'.
Sometimes, I feel like punting the whole issue and implementing a
package system for Guile, like Common Lisp has, and be done with it.
It might not be elegant, it might not be Schemey, but it solves a lot
of real world issues, it is `standard' and a lot of people understand
it already.
- Re: Macro uexpansion, (continued)
- Re: Macro uexpansion, Mikael Djurfeldt, 2000/12/19
- Re: New module system, Jim Blandy, 2000/12/19
- Re: New module system, Mikael Djurfeldt, 2000/12/19
- 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 <=