[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Environment-objects don't exist in CL according to manual
- To: REM%IMSSS@SU-SCORE.ARPA (temporary until nameservers up)
- Subject: Environment-objects don't exist in CL according to manual
- From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
- Date: Mon, 10 Jun 1985 14:49:00 -0000
- Cc: COMMON-LISP@SU-AI.ARPA
- Sender: FAHLMAN@CMU-CS-C.ARPA
Assuming that something doesn't exist in Common Lisp just because it
doesn't appear in the index of the manual is a pretty risky business.
In fact, this business of environment objects would probably be indexed
under &environment, but all the &-thingies got left out of the index.
In this case, the problem is compounded by a serious typo in the text.
The use of &evironment in the arglist of a defmacro is described on page
145 at the very bottom. In my copy of the manual, at least, the actual
word "&environment" got left out, but it is supposed to be the label for
the last paragraph on this page, after the paragraph describing &whole.
Uses of these environment objects are described under macroexpand and
macroexpand-1, and also under the hook functions in the Eval chapter.
Subsequent discussion has revealed that you also need these environment
objects as arguments to the proposed PARSE-BODY, to MACRO-FUNCTION, and
also to GET-SETF-METHOD. Arguably also to EVAL, because of the damned
macro-> declaration business, but I'm not sure about that. Basically,
everyone who might have to expand a macro as part of the expansion of
another macro has to receive the environment object so that lexically
defined macros are handled properly.
I have come around to the conclusion that we really blew it when we let
MACROLET into the language, despite that operator's occasional
usefulness. If not for that, none of this environment hackery would be
necessary, and macro->declaration processing would be straightforward.