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

["Steve Bacher (Batchman)" <SEB1525@draper.com>]

 From:	IN%"sandra%defun@cs.utah.EDU"  "Sandra J Loosemore"  6-JAN-1989 19:53
To:	"Steve Bacher (Batchman)" <SEB1525@DRAPER.COM>
Subj:	Re: Issue EVAL-WHEN-NON-TOP-LEVEL, v2

>> Many common uses of EVAL-WHEN would have different behavior.  e.g.:
>> (eval-when (compile load eval)
>>  (proclaim '(special foo))   ; make FOO special to compiler and in compiled code  
>>  (defun some-function (...) ...)  ; make a function definition available, etc.
>>  (define-setf-method ...)         ; you get the idea by now...
>>  ...
>> )
>
>Ummm, I'm not sure how taking away the top-level-ness of the body of
>the EVAL-WHEN would change the behavior of this example.  Since the
>COMPILE situation causes the body to be evaluated as an explicit PROGN
>*before* any other normal compiler processing of the body, the
>PROCLAIM will still get evaluated at compile time, SOME-FUNCTION will
>be defined in at compile time, and the DEFINE-SETF-METHOD will be
>defined at compile time.  Can you please clarify why you think this
>example would break?

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?  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?  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
)