[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: "cl-compiler" <email@example.com>
- Subject: issue EVAL-WHEN-NON-TOP-LEVEL
- From: "AITG::VANROGGEN" <firstname.lastname@example.org>
- Date: 20 May 88 11:19:00 EDT
- Cc: vanroggen
- Reply-to: "AITG::VANROGGEN" <email@example.com>
Overall, this proposal looks pretty good, if a clarification and "compatible"
extension is what we want.
I think that in addition to specifying the environments for the different
situations, the major change in this proposal may appear to be the meaning of
the LOAD situation. I would like to believe that the intent of the LOAD
situation has always been to make the body of the EVAL-WHEN be compiled, not
the more obvious intent (judging by the name) of EVALuating the body when the
compiled file is being LOADed.
The latter interpretation is perfectly consistent with the former as long as
the EVAL-WHEN is at top-level in the file. Since we want to assign a meaning to
EVAL-WHEN when not at top-level, the former interpretation makes more sense and
would be compatible between the old and the new semantics.
Another reason why this interpretation is necessary is that non-top-level
EVAL-WHEN's ought to work fine when COMPILE is being used to compile
functions, not just when used in files being processed by COMPILE-FILE.
I believe that explicitly stating this interpretation will make it easier
for people to understand why the LOAD situation doesn't mean what they may
think it means. Although I believe my interpretation is what you mean to
To the compiler, (EVAL-WHEN (LOAD) ...) is equivalent to a
PROGN form; the compiler simply arranges for the body to be
``evaluated'' in the lexical environment in which the EVAL-WHEN form
it might still not be clear to some readers. [But the macro definition
of EVAL-WHEN helps a lot.] Perhaps a historical note about compilers
normally being file compilers will help also.
The related thing which people might be confused with is what happens
with "#,". The reason why I suggested this proposal, which I agree with,
might not be sufficient is that it doesn't address the ability to
evaluate forms at LOAD time. But maybe this proposal along with another
one to add a special form to do LOAD-time evaluation for side-effects
and constant-values will be acceptable.
A major nit (!?): Isn't there a cleanup proposal to disallow lexically
binding special-forms in FLET, LABELS, and MACROLET? If so, your
EVAL-WHEN macro is doing a no-no. You might want to change the statement
from "suggested implementation technique" to "implemented as if".
For the Current Practice section, VAX LISP implements the proposed
changes already, except that it doesn't always substitute NIL when the
situation doesn't apply. (There are times when the whole form just
disappears rather than returning NIL.)