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

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

> Date: Mon 2 Jan 89 17:28:34-PST
> From: Kim A. Barrett <IIM@ECLA.USC.EDU>
> 
> Now the real question is, is this really what we want to do?  I certainly
> didn't expect my "strawman" proposal to get through unscathed.

Well, I'm glad that the writeup is at least making sense now.  

I personally don't have particularly strong feelings on this issue.  I
think that the most questionable aspect of the current proposal is
that it can cause multiple evaluations if you have nested EVAL-WHENs,
for example

    (eval-when (eval compile load)
        (eval-when (eval compile load)
	    (this-fn-gets-called-twice-at-compile-time)))

I can think of some rather contrived examples where the second
compile-time evaluation in the inner EVAL-WHEN might get screwed up by
side-effects of subsequent forms in the outer EVAL-WHEN (such as
SETQ'ing a global variable it depends on). 

One possible "fix" would be to specify that EVAL-WHEN doesn't pass
"top-level-ness" on to its body if both the COMPILE and LOAD
situations are specified (thus suppressing the second evaluation of
the nested EVAL-WHENs), but I'm not convinced that wouldn't cause some
additional problems of its own. 

Anybody else have thoughts on this?

-Sandra
-------