166 lines
9.4 KiB
HTML
166 lines
9.4 KiB
HTML
<!-- Common Lisp HyperSpec (TM), version 7.0 generated by Kent M. Pitman on Mon, 11-Apr-2005 2:31am EDT -->
|
|
<HTML>
|
|
<HEAD>
|
|
<TITLE>CLHS: Issue EVAL-TOP-LEVEL Writeup</TITLE>
|
|
<LINK HREF="../Data/clhs.css" REL="stylesheet" TYPE="text/css" />
|
|
<META HTTP-EQUIV="Author" CONTENT="Kent M. Pitman">
|
|
<META HTTP-EQUIV="Organization" CONTENT="LispWorks Ltd.">
|
|
<LINK REL=TOP HREF="../Front/index.htm">
|
|
<LINK REL=COPYRIGHT HREF="../Front/Help.htm#Legal">
|
|
<LINK REL=DISCLAIMER HREF="../Front/Help.htm#Disclaimer">
|
|
<LINK REL=PREV HREF="../Issues/iss145_w.htm">
|
|
<LINK REL=UP HREF="../Issues/iss146.htm">
|
|
<LINK REL=NEXT HREF="../Issues/iss147_w.htm">
|
|
</HEAD>
|
|
<BODY>
|
|
<H1><A REV=MADE HREF="http://www.lispworks.com/"><IMG WIDTH=80 HEIGHT=65 ALT="[LISPWORKS]" SRC="../Graphics/LWSmall.gif" ALIGN=Bottom></A><A REL=TOP HREF="../Front/index.htm"><IMG WIDTH=237 HEIGHT=65 ALT="[Common Lisp HyperSpec (TM)]" SRC="../Graphics/CLHS_Sm.gif" ALIGN=Bottom></A> <A REL=PREV HREF="../Issues/iss145_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Previous]" SRC="../Graphics/Prev.gif" ALIGN=Bottom></A><A REL=UP HREF="../Issues/iss146.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Up]" SRC="../Graphics/Up.gif" ALIGN=Bottom></A><A REL=NEXT HREF="../Issues/iss147_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Next]" SRC="../Graphics/Next.gif" ALIGN=Bottom></A></H1>
|
|
|
|
<HR>
|
|
|
|
|
|
|
|
<H2>Issue EVAL-TOP-LEVEL Writeup</H2>
|
|
|
|
<PRE><B>Forum:</B> Public Review<P>
|
|
<B>Issue:</B> <A HREF="iss146.htm">EVAL-TOP-LEVEL</A><P>
|
|
<B>References:</B> Loosemore's public review comment #29 (X3J13/92-1329)<P>
|
|
Section 3.2.3.1, "Processing of Top Level Forms"<P>
|
|
<A REL=DEFINITION HREF="../Body/f_eval.htm#eval"><B>EVAL</B></A>, <A REL=DEFINITION HREF="../Body/f_load.htm#load"><B>LOAD</B></A>, <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A><P>
|
|
Issue <A HREF="iss147.htm">EVAL-WHEN-NON-TOP-LEVEL</A><P>
|
|
<B>Category:</B> CLARIFICATION, CHANGE<P>
|
|
<B>Edit history:</B> 12 Dec 90, Version 1 by Tim Moore<P>
|
|
14 Dec 90, Version 2 by Moore w/ comments from Loosemore<P>
|
|
08 Mar 91, Version 3 by Moore, discussion from rwk and JonL<P>
|
|
06 Feb 93, Version 4 by Loosemore<P>
|
|
(new proposal, update writeup)<P>
|
|
<B>Status:</B> Proposal LIKE-COMPILER (version 3) failed 4-9 at<P>
|
|
the March 1991 meeting.<P>
|
|
Proposal LOAD-LIKE-COMPILE-FILE passed 5-2 at the<P>
|
|
October 1993 meeting.<P>
|
|
<P>
|
|
<P>
|
|
<B>Problem description:<P>
|
|
</B><P>
|
|
Section 3.2.3.1, "Processing of Top Level Forms" specifies the <P>
|
|
processing of top-level forms in the file compiler in great detail.<P>
|
|
Unfortunately, there is no such specification of the evaluator or<P>
|
|
loader's top level behavior. If the evaluator or loader does not <P>
|
|
process top-level forms in the same way that the compiler does, there <P>
|
|
can be a surprising semantic gap between the compiler and interpreter.<P>
|
|
It may be impossible to evaluate forms that <A REL=DEFINITION HREF="../Body/f_mexp_.htm#macroexpand"><B>macroexpand</B></A> into more than <P>
|
|
one top-level form. For example:<P>
|
|
<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_progn.htm#progn"><B>progn</B></A><P>
|
|
(<A REL=DEFINITION HREF="../Body/m_defset.htm#defsetf"><B>defsetf</B></A> foo setf-foo)<P>
|
|
(<A REL=DEFINITION HREF="../Body/m_defun.htm#defun"><B>defun</B></A> bar (u v)<P>
|
|
(<A REL=DEFINITION HREF="../Body/a_setf.htm#setf"><B>setf</B></A> (foo u) v)))<P>
|
|
<P>
|
|
If the <A REL=DEFINITION HREF="../Body/m_defset.htm#defsetf"><B>DEFSETF</B></A> form is not evaluated before the function definition is<P>
|
|
processed, the <A REL=DEFINITION HREF="../Body/a_setf.htm#setf"><B>SETF</B></A> form will expand incorrectly into:<P>
|
|
<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_funcal.htm#funcall"><B>funcall</B></A> (<A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>function</B></A> (<A REL=DEFINITION HREF="../Body/a_setf.htm#setf"><B>setf</B></A> foo)) v u)<P>
|
|
<P>
|
|
instead of:<P>
|
|
<P>
|
|
(setf-foo u v)<P>
|
|
<P>
|
|
The net result is that code which has been carefully structured to<P>
|
|
compile correctly under the order-of-processing constraints given in<P>
|
|
section 3.2.3.1 may fail to work when loaded interpretively.<P>
|
|
<P>
|
|
At least two implementations -- UCL and WCL -- have unwittingly <P>
|
|
stumbled into this trap by implementing evaluators that perform<P>
|
|
implicit compilation before executing any code.<P>
|
|
<P>
|
|
<P>
|
|
<B>Proposal (EVAL-TOP-LEVEL:LOAD-LIKE-COMPILE-FILE):<P>
|
|
</B><P>
|
|
Replace the fourth paragraph of the description section of the<P>
|
|
dictionary entry for <A REL=DEFINITION HREF="../Body/f_load.htm#load"><B>LOAD</B></A> with:<P>
|
|
<P>
|
|
\funref{load} sequentially executes each \term{form} it encounters<P>
|
|
in the file named by \param{filespec}. If the file is a source<P>
|
|
file and the implementation chooses to perform <P>
|
|
\term{implicit compilation}, \funref{load} must recognize<P>
|
|
\term{top level forms} as described in {\secref\TopLevelForms} and<P>
|
|
arrange for each \term{top level form} to be executed before<P>
|
|
beginning \term{implicit compilation} of the next. (Note, however, <P>
|
|
that processing of \specref{eval-when} forms by \funref{load} is <P>
|
|
controlled by the \kwd{execute} situation.)<P>
|
|
<P>
|
|
<P>
|
|
<B>Rationale:<P>
|
|
</B><P>
|
|
Everybody seems to agree that it's a bug for implementations *not*<P>
|
|
to be able to load files containing top-level forms such as that<P>
|
|
given in the problem description section. Having the <A REL=DEFINITION HREF="../Body/07_ffb.htm#standard"><B>standard</B></A> say<P>
|
|
something explicit about it will hopefully prevent implementors<P>
|
|
from overlooking this source of bugs in the future.<P>
|
|
<P>
|
|
<P>
|
|
<B>Current practice:<P>
|
|
</B><P>
|
|
UCL and WCL have had problems with this in the past. It's not known<P>
|
|
whether or how they have been fixed.<P>
|
|
<P>
|
|
<P>
|
|
<B>Cost to implementors:<P>
|
|
</B><P>
|
|
In those implementations that do implicit compilation, minor hacks<P>
|
|
to make <A REL=DEFINITION HREF="../Body/f_load.htm#load"><B>LOAD</B></A> or <A REL=DEFINITION HREF="../Body/f_eval.htm#eval"><B>EVAL</B></A> to do stuff similar to the top-level <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A><P>
|
|
processing. None in other implementations.<P>
|
|
<P>
|
|
<P>
|
|
<B>Cost to users:<P>
|
|
</B><P>
|
|
None.<P>
|
|
<P>
|
|
<P>
|
|
<B>Aesthetics:<P>
|
|
</B><P>
|
|
Neutral.<P>
|
|
<P>
|
|
<P>
|
|
<B>Editorial impact:<P>
|
|
</B><P>
|
|
Inserting the text included above.<P>
|
|
<P>
|
|
(It would probably be better to reorganize this material into a separate<P>
|
|
section describing program <A REL=DEFINITION HREF="../Body/f_docume.htm#structure"><B>structure</B></A> rather than talking about <A REL=DEFINITION HREF="../Body/s_the.htm#the"><B>the</B></A><P>
|
|
behavior of <A REL=DEFINITION HREF="../Body/f_load.htm#load"><B>LOAD</B></A> <A REL=DEFINITION HREF="../Body/a_and.htm#and"><B>and</B></A> <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A>, but that's too much work!)<P>
|
|
<P>
|
|
<P>
|
|
<B>Discussion:<P>
|
|
</B><P>
|
|
Sandra Loosemore says:<P>
|
|
<P>
|
|
I submitted this as a public review comment after I discovered that<P>
|
|
WCL was "broken" while trying to port some code last fall. I had <P>
|
|
completely forgotten that the exact same problem had previously <P>
|
|
been presented as a cleanup issue to the committee until Kim Barrett <P>
|
|
mentioned it while we were sorting through the comments after the <P>
|
|
end of the public review period.<P>
|
|
<P>
|
|
Version 3 of this issue contained a different proposal, LIKE-COMPILER,<P>
|
|
which would have constrained <A REL=DEFINITION HREF="../Body/f_eval.htm#eval"><B>EVAL</B></A> rather than <A REL=DEFINITION HREF="../Body/f_load.htm#load"><B>LOAD</B></A>. That proposal was<P>
|
|
defeated at the March 1991 meeting, with people who voted against the<P>
|
|
proposal arguing that<P>
|
|
<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_eval.htm#eval"><B>eval</B></A> x) <P>
|
|
<P>
|
|
should have completely equivalent semantics to<P>
|
|
<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_funcal.htm#funcall"><B>funcall</B></A> (<A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>compile</B></A> <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>nil</B></A> `(<A REL=DEFINITION HREF="../Body/a_lambda.htm#lambda"><B>lambda</B></A> () ,x)))<P>
|
|
<P>
|
|
The LOAD-LIKE-COMPILE-FILE proposal in version 4 avoids this problem<P>
|
|
by constraining <A REL=DEFINITION HREF="../Body/f_load.htm#load"><B>LOAD</B></A> only. However, it may be implemented either by<P>
|
|
tweaking <A REL=DEFINITION HREF="../Body/f_load.htm#load"><B>LOAD</B></A> specifically or <A REL=DEFINITION HREF="../Body/f_eval.htm#eval"><B>EVAL</B></A> in general to process forms in <P>
|
|
the required order.<P>
|
|
</PRE>
|
|
<HR>
|
|
|
|
<A REL=NAVIGATOR HREF="../Front/StartPts.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Starting Points]" SRC="../Graphics/StartPts.gif" ALIGN=Bottom></A><A REL=TOC HREF="../Front/Contents.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Contents]" SRC="../Graphics/Contents.gif" ALIGN=Bottom></A><A REL=INDEX HREF="../Front/X_Master.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Index]" SRC="../Graphics/Index.gif" ALIGN=Bottom></A><A REL=INDEX HREF="../Front/X_Symbol.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Symbols]" SRC="../Graphics/Symbols.gif" ALIGN=Bottom></A><A REL=GLOSSARY HREF="../Body/26_a.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Glossary]" SRC="../Graphics/Glossary.gif" ALIGN=Bottom></A><A HREF="../Front/X3J13Iss.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Issues]" SRC="../Graphics/Issues.gif" ALIGN=Bottom></A><BR>
|
|
|
|
<A REL=COPYRIGHT HREF="../Front/Help.htm#Legal"><I>Copyright 1996-2005, LispWorks Ltd. All rights reserved.</I></A><P>
|
|
</BODY>
|
|
</HTML>
|