Re: Unmemoization of macros

[Mikael Djurfeldt]

[Mikael's obligatory additional note follows here.  Also: Note the
 dangerous omission of address@hidden in the message header]

Mikael Djurfeldt <address@hidden> writes:

> This motivates why it is OK to modify the simple interpreter model by
> adding that the interpreter *may* be smart and not do the translation
> every time, but promises to do so if the macro has changed.

I almost forgot the most important thing:

What is so great about this simple model that we would like to make
these efforts?

Answer: The macro abstraction works symmetrically to the procedure
abstraction in the sense that just as top-level procedure references
in the body of a definition always refer to the most recently
evaluated definition of that name, the same holds true also for
top-level macro references.

This avoids the thready complexity of this symmetry holding under some
conditions (macro/interpreted code) but not under others
(mmacro/compiled code), and, in this latter case, of the macro uses
having the semantics of a definition which *happened* to exist at some
point in time between the definition of the procedure under
consideration and "now", a complexity which has very bad,
non-intuitive, unpractical consequences during everyday development
work.