[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue EVAL-WHEN-NON-TOP-LEVEL, v2
- To: Jon L White <jonl@lucid.com>
- Subject: Re: Issue EVAL-WHEN-NON-TOP-LEVEL, v2
- From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
- Date: Tue, 3 Jan 89 17:01:54 MST
- Cc: sandra%defun@cs.utah.edu, IIM@ECLA.USC.EDU, cl-compiler@SAIL.STANFORD.EDU
- In-reply-to: Jon L White <jonl@lucid.com>, Tue, 3 Jan 89 15:29:01 PST
> Date: Tue, 3 Jan 89 15:29:01 PST
> From: Jon L White <jonl@lucid.com>
>
> Hmmmm, maybe KIM's solution still doesn't dispense with the need to do
> a MACROLET on EVAL-WHEN so that nested eval-whens can have the correct
> semantics.
Gag! Retch! :-)
Seriously, I think it would be an extremely bad idea to make
EVAL-WHEN's notion of when to perform compile-time magic different
than the standard notion of top-level-ness. Besides it being
confusing, one wouldn't be able to use EVAL-WHEN to implement the
magical compile-time behavior of the various defining macros. I
suppose that if we made the defining macros behave the same way, it
would be somewhat more reasonable, but in that case why not just
change the definition of top-level?
-Sandra
-------