common lisp- &environment objects

["Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>]

    I'm arguing that CLtL says much too little about environments.  It does
    not say how to get your hands on one, but specifies them as optional
    arguments to functions, for example EVALHOOK, APPLYHOOK, MACROEXPAND(-1)
    (and in our implementation EVAL).  Dynamic extent isn't good enough; how
    can you do upward funargs?  This is far from cute:
    	(defun adder (val)
    	  #'(lambda (x) (+ x val)))
    it is instead at the heart of lexical scoping.

Ah, OK, we've got some misunderstanding here between the general concept
of an environment and the specific concept of an environment object, as
returned by &environment.  I agree that lexical closures have to work,
and that this requires that some parts of the environment in which a
function is closed be saved with indefinite extent.  However, this
doesn't say that environment objects must have indefinite extent.  It
doesn't even say that the lexical variable part of the environment has
to be saved or has to be an object with indefinite extent.  In our
current (inefficient) Spice Lisp interpreter, this environment is a
consed A-list, but one could certainly imagine an implementation that
stack allocated this structure (with provision for saving it if a
closure is created) or some sort of shallow-bound variable environment
that never has a specific object that represents the current variable
environment, but that somehow arranges to save all the right value cells
when a closure is created.  So I agree that closures have to work, but
not that this implies anything about the extent of environment objects.

In speaking of the expense of diddling variable values, I am referring
to those values that are not part of any lexical closure, but that might
somehow still be accessible if we were to take seriously the notion that
environment objects can be kept alive indefinitely and passed around.  I
don't think we want to allow this.  We do, of course, have to make sure
that properly created lexical closures work properly, but we should not
specify the internal mechanism that makes that possible.  Parts of the
lexical function name environment must similarly be of indefinite extent
if FLET and LABELS are to work properly, but again we do not need to
keep the entire environment around in order to accomplish this.

Clearly go-tags and block-names want to become inoperative outside of
the dynamic extent of their blocks, whatever we decide about the extent
of environment objects.

So again the question is whether we can accomplish everything we need to
with environment objects even if these objects have only dynamic extent.
Whether some parts of the environment need to have indefinite extent in
order to make closures work is a different question, I think.

-- Scott