guile-devel
[Top][All Lists]
Advanced

[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.



reply via email to

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