extent of environments

[Charles Hedrick <HEDRICK@RUTGERS.ARPA>]

TOPS-20 Common Lisp in fact does precisely what Scott conjectured
a hypothetical implementation might do:  We put the environment
information on the stack.  We copy it into the heap whenever we have
to give the information to the user.  This seems to speed up the
interpreter a lot.  If somebody can guarantee us that the things
we give to a macro with &environment can safely be left on the
stack, that would speed up those macro expansions.  This is not
critical, however, since we only do macro expansions once.  (We
use the old UCI Lisp displacement technique.)  What has actually
stopped us from doing &environment is not this problem (which is
trivial to fix - after all we already have the function to copy
the environment into the heap) but the fact that we have to make
the compiler do it also.  Thus the compiler is going to have to
construct an environment which will look to the macro 7s if it were
the runtime enviornment in which the macro was called.  The copy
of Spice Lisp that we have (which may, as usual, be slightly
out of date) simply doesn't deal with these issues.  Indeed in
SETF they have a separate macro expander that explicitly tests
whether it is in the compiler or not.  We are going to have to
replace that with a new mechanism that does things right.  The 
whole implementation of macros that expand to declarations and
&environment seems to be one single knotted mess, which I will
solve the first time I get a weekend that I can devote to it.
-------