[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


   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.