[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue EVAL-WHEN-NON-TOP-LEVEL
- To: sandra@cs.utah.edu (Sandra J Loosemore)
- Subject: Re: issue EVAL-WHEN-NON-TOP-LEVEL
- From: Rob.MacLachlan@WB1.CS.CMU.EDU
- Date: Fri, 20 May 88 17:04:48 EDT
- Cc: cl-compiler@sail.stanford.edu
- In-reply-to: Your message of Fri, 20 May 88 13:29:58 -0600. <8805201929.AA05454@cs.utah.edu>
From: sandra@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8805201929.AA05454@cs.utah.edu>
Date: Fri, 20 May 88 13:29:58 MDT
Subject: Re: issue EVAL-WHEN-NON-TOP-LEVEL
To: Rob.MacLachlan@wb1.cs.cmu.edu
> Date: Fri, 20 May 88 14:59:13 EDT
> From: Rob.MacLachlan@WB1.CS.CMU.EDU
>
> In this form, I believe (FOO) would never be evaluated in
> any context, which is definitely an incompatible change:
> (eval-when (compile)
> (eval-when (compile)
> (foo)))
Yes, you are correct that under the current proposal, (foo) would never
be evaluated. I do not think it is "definitely" an incompatible change,
however. The current wording in CLtL seems to leave this behavior
unspecified and I don't know what the original intention was.
I guess CLTL does leave that one hanging. But this deserves at least some
compatibility/current practice note in the proposal. This is incompatible
with at least our implementation.
The behavior you suggest seems non-intuitive to me. The whole theory
behind EVAL-WHEN is that there are these independently composable
situations, any combination of which may be specified. Specifying a
particular situation has a particular effect, independently of what other
situations are present. In particular, specifying the COMPILE situation
guarantees that the body will be evaluated at compile time.
Of course, as I have pointed out before, the theory behind EVAL-WHEN is
wrong, so it isn't clear how upset we should be about mental models of
EVAL-WHEN being violated.
Rob