[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
First Class environments in CL ??
- To: beckerle@MIT-XX.ARPA
- Subject: First Class environments in CL ??
- From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
- Date: Mon, 12 May 86 15:13 EDT
- Cc: common-lisp@SU-AI.ARPA
- In-reply-to: The message of 12 May 86 14:01 EDT from mike@ALLEGHENY.SCRC.Symbolics.COM
Date: Mon, 12 May 86 13:01 EST
Can you obtain a first-class
handle on a lexical environment in CL???
Common Lisp only supports lexical closures as first-class objects. Each
implementation has (perhaps too much) freedom to implement the
environments embedded inside those closures however it wants. The
motivation for this freedom is to permit efficient compilation.
We should do one of the following:
(1) eliminate the 'env' optional to evalhook/applyhook.
(2) provide a selector which extracts the current lexical environment
and returns it so that it can be stored as any first class object.
I prefer (1) since it makes compilation much easier and more effective.
Compiled code does not set off *evalhook* and *applyhook*, so this 'env'
facility does not affect compilation in any way.
I believe the env argument to the function applyhook to be a typographical
error, since there is no meaningful way that that argument could be used.
Our implementation ignores it. I have not investigated, but I expect
every other implementation ignores it too.
It would be impossible for the evalhook function to operate correctly
without an env argument, since a form is only meaningful for evaluation
in some particular lexical environment. The book doesn't explain this
very well, but it should be apparent after studying the example on page
323. The only valid value for the env argument to the evalhook function
is, I believe, a value that was received as the second argument to a
function that is the value of *evalhook*, or nil.
Finally, to avoid confusion, In CLtL, there is a discussion of the
&environment keyword for macros. It specifically says that this
environment may not be complete, and should only be used with
"macroexpand" and is constructed by "macrolet". This is clearly
not the environment intended for use with evalhook.
I agree with you. It is permitted, but not required, to be the same
environment. In our implementation, it is the same environment in some
contexts and is something else in other contexts.