common lisp- &environment objects

[David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>]

    Date: Wed, 5 Jun 1985  22:06 EDT
    From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>


     The book is silent in the question of the extent of environments as delivered
     to &environment bindings in DEFMACRO, hook functions, etc.  What shall we say?

    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.