Dave Moon's summary of EVAL-WHEN issues.

[Christopher Fry <cfry@OZ.AI.MIT.EDU>]

    Received: from MC.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 9 Apr 86 22:47-EST
    Received: from SU-AI.ARPA by MC.LCS.MIT.EDU  9 Apr 86 22:46:46 EST
    Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 9 Apr 86  19:21:07 PST
    Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 9 Apr 86 22:21:52-EST
    Date: Wed, 9 Apr 1986  22:21 EST
    Message-ID: <FAHLMAN.12197597061.BABYL@C.CS.CMU.EDU>
    Sender: FAHLMAN@C.CS.CMU.EDU
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
    To:   common-lisp@SU-AI.ARPA
    Subject: Dave Moon's summary of EVAL-WHEN issues.
    In-reply-to: Msg of 4 Apr 1986  13:37-EST from Bobrow.pa at Xerox.COM


    I think that instead of worrying about changing the name, we need to
    completely replace the current Eval-When.  We need to figure out what
    kinds of control we need over when things are to be evaluated, compiled,
    etc., and then we need good clean ways of expressing these directives in
    portable code files.  This is all tied in with top-level forms and
    issues about what the compiler does to the compile-time and load-time
    environments.  Once we know what sorts of operations we want to
    support, then we should worry about names.  Assuming that these new
    controls are not equivalent to the current Eval-When, we will want new
    names for these things so that the cut-over fromt he old Eval-When can
    occur gradually.
    -- Scott
As the instigator of this round of eval-when-wars, I was horrified at the
volume of mail generated on the topic over the last couple of weeks.
Scott is EXACTLY right! 

Perhaps a few coherent proposals could be passed
out and/or expalined at the upcomming meeting.