[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
common lisp- &environment objects
- To: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>, Guy Steele <gls@THINK.ARPA>
- Subject: common lisp- &environment objects
- From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
- Date: Sun, 9 Jun 85 15:01 EDT
- Cc: common-lisp@SU-AI.ARPA
- In-reply-to: <FAHLMAN.12116842945.BABYL@CMU-CS-C.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.