Re: Issue: EVAL-WHEN-NON-TOP-LEVEL

[sandra%defun@cs.utah.edu (Sandra J Loosemore)]

> Date: Tue, 20 Sep 88 08:29:38 PDT
> From: vanroggen%aitg.DEC@decwrl.dec.com
> 
> I think there's still a serious flaw with EVAL-WHEN-NON-TOP-LEVEL.  I
> had sent mail about this before, but I don't think it received enough
> consideration.
> 
> The problem concerns the order of evaluation of forms that are inside an
> (EVAL-WHEN (COMPILE ...) ...) with respect to each other and their effects
> on other code to be "processed".
> 
> Let's assume DEFMACRO expands into something that includes an EVAL-WHEN
> (COMPILE) that tells the compiler that the macro is a macro and what it
> should expand into.
> 
>   (LET ...
>     (DEFMACRO M ...)
>     (M ...))
> 
> But this code should be exactly equivalent to:
> 
>   (LET ...
>     (FLET ((REST-OF-BODY () (M ...)))
>       (DEFMACRO M ...)
>       (REST-OF-BODY)))
> 
> Yet the latter code won't have M be treated as a macro in the definition
> of REST-OF-BODY.  Since this transformation is fairly fundamental, it seems
> to me we can't make the former piece of code allow the DEFMACRO to define
> M for use in the rest of the body.

I'm not sure what the problem is.  Section (5) of the proposal
explicitly says that you can't depend upon the DEFMACRO being
processed before the reference to the macro it defines, since they
both appear in the same top-level form.  I remember putting this in
when you brought up this issue before.  If I've misunderstood the
problem, can you please be more specific about what you would like to
have changed in the proposal? 

-Sandra
-------