[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue EVAL-WHEN-NON-TOP-LEVEL
- To: Jon L White <edsel!jonl@labrea.stanford.edu>
- Subject: Re: issue EVAL-WHEN-NON-TOP-LEVEL
- From: sandra@cs.utah.edu (Sandra J Loosemore)
- Date: Sat, 21 May 88 10:11:25 MDT
- Cc: labrea!vanroggen%aitg.decnet@hudson.dec.com, cl-compiler@sail.stanford.edu, vanroggen@sail.stanford.edu
- In-reply-to: Jon L White <edsel!jonl@labrea.stanford.edu>, Sat, 21 May 88 04:42:51 PDT
> Date: Sat, 21 May 88 04:42:51 PDT
> From: Jon L White <edsel!jonl@labrea.stanford.edu>
>
> This proposal changes EVAL-WHEN from being a special-form into being a
> MACRO [that expands into some readily-understandable(?) code]. Thus it
> wouldn't be subject to the no-shadowing-of-special-forms rule.
Well, it doesn't go quite that far. In the new, revised version of the
proposal, I was going to say that EVAL-WHEN behaves *as if* it were
implemented as a macro. Changing its "official" status from special form
to macro is a somewhat larger step.
I can think of cases where user code would still want to think of it as
a special form, particularly if we don't decide to make the *compiling-p*
variable public. For instance, if you're trying to implement some kind
of a code-walking preprocessor, you would probably want it to leave the
EVAL-WHENs in place since the context in which the preprocessor executes
may not be the same as the context in which the code it produces is to
be processed.
I will bow to the wishes of the subcommittee on this issue. I do think
we need to make a decision one way or the other and include the rationale
in the proposal, because somebody else is bound to bring it up later on.
-Sandra
-------