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

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

> Sure, those things would get evaluated at compile time.  What I'm
> worried about is the compiler's particular handling of those forms at
> top level - for example, the compiler has to do magic things with
> PROCLAIM when it sees it at top level, otherwise the proclamation
> won't work, right?  

There is nothing in CLtL that says that PROCLAIM has magic
compile-time behavior at top-level.  We do have an issue around to
deal with this, but it's been tabled while we see what the sentiment
is for removing the magic behavior of the package functions.  As
things stand now, for portable behavior you *must* wrap the PROCLAIM
in an EVAL-WHEN if you want it to affect compilation. 

> In that case, if the compiler doesn't think that
> there's a PROCLAIM at top level because it happens to have been
> wrapped in an EVAL-WHEN, we can only lose, right?  

Since the compiler has already evaluated the PROCLAIM because of the
COMPILE situation being specified to the EVAL-WHEN, why evaluate it
again?  Why isn't it sufficient just to compile it normally?

> User-defined SETF
> methods would have the same problem.  The exhortations to users to
> wrap such things in (eval-when (compile load eval) ...) would be
> inadequate.  Users might even have to do
>  
> (define-setf-method . lots-of-complicated-hair) 
> (eval-when (compile)
>  (define-setf-method . lots-of-complicated-hair)
>  ; i.e. the same hair, duplicated
> )

I still don't understand what you think the problem would be.  You'll
have to be much more specific about it -- provide an example and step
through it, describing exactly what will go wrong.

-Sandra
-------