[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue DEFINING-MACROS-NON-TOP-LEVEL
- To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
- Subject: Re: issue DEFINING-MACROS-NON-TOP-LEVEL
- From: sandra@cs.utah.edu (Sandra J Loosemore)
- Date: Tue, 24 May 88 13:50:13 MDT
- Cc: "cl-compiler" <cl-compiler@sail.stanford.edu>
- In-reply-to: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>, 23 May 88 14:06:00 EDT
> Date: 23 May 88 14:06:00 EDT
> From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
>
> Except this is still true:
> (let ((x (f)))
> (defmacro m (y) `(+ ,x ,y)))
> ...
> (defun g (...)
> ... (m ...) ...)
> and inside G the use of M is an error because it isn't guaranteed to be
> recognized as a call to a macro.
I don't think this follows from our model of how the defining macros
do their thing at compile time, and how EVAL-WHEN works at
non-top-level. The DEFMACRO presumably would expand into an (EVAL-WHEN
(COMPILE) ...) to store the macro definition for the compiler, and as
long as the compiler processes this before it runs across any calls to
the macro, this example would be OK (that is, if it were not for the
problem of the macro function getting defined in the wrong lexical
environment).
If you want the defining macros to have their compile-time side-effects
occur only if they appear at top-level, I think we have to come up with
some other model to explain how this happens (other than saying that
they expand into EVAL-WHENs). Do we really want to do that?
-Sandra
-------