[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Dave Moon's summary of EVAL-WHEN issues.
- To: Fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA
- Subject: Dave Moon's summary of EVAL-WHEN issues.
- From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
- Date: Thu, 10 Apr 86 03:05 EST
- In-reply-to: <FAHLMAN.12197597061.BABYL@C.CS.CMU.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
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
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
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.