common lisp- &environment objects

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

        One false move here and we have not Lisp but Conniver.  How about
        requiring "dynamic" extent for environment objects, and no more?  Will
        that take care of the needs for macro-expansion, steppers, and so on?
        True, you could imagine cute ways of using environments that outlive
        their invocations, but I REALLY don't want to pay for those cute uses
        with inefficiency or severe constraints on the implementor.  If anyone
        wants to implement Conniver in Common Lisp, I can supply the old Maclisp
        code, but let's not drag down Common Lisp itself.

    Moon very carefully solved this problem in Symbolics' implementation of
    Common Lisp by having an &ENVIRONMENT keyword to defmacro and making
    sure all possible expanders of macros took an optional environment
    argument, to which they can pass to MACROEXPAND(-1).  This isn't cute;
    it is functional.  It isn't inefficient and it doesn't pose any
    constraints on the implementor, unless I misunderstand what "the
    implementor" is suposed to mean.

I don't understand what you are saying here.  What does this have to do
with the extent of environment objects?  What, exactly, are you arguing
for?

As I said in an immediate follow-up to the above message, you only get a
lot of additional expense if you actually let users do all of the
"obvious" things with an immortal environment object, such as going to
the tags and diddling the lexical variables.  I really don't care if
environment objects have indefinite or dynamic extent, as long as these
expensive kinds of uses are clearly forbidden once you exit the dynamic
extent, but the politics of this group are such that we must be very
careful about introducing features that, if taken to their logical
conclusion, lead us to somewhere we don't want to go; there are always a
lot of people who demand that everything be taken to its logical
conclusion, and damn the expense, so it is sometimes better not to take
the first step.

I do note that the original query suggested that Symbolics was
stack-allocating environment objects, and other implementations might
want to do similarly tense things in order to make the interpreter
reasonably cons-free.  That suggests to me that it would be a good idea
to allow environment objects to have dynamic extent only, unless someone
can explain why this is unworkable or can demonstrate some important
thing that cannot be done if we take this position.  I am always
nervous about disappearing objects, such as the disappearing &rest args
in Zetalisp (not legal in Common Lisp), but in the case of environment
arguments we might choose to go with a dangerous but efficient solution.

-- Scott