211 lines
14 KiB
HTML
211 lines
14 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 PROCLAIM-ETC-IN-COMPILE-FILE 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/iss277_w.htm">
|
|
<LINK REL=UP HREF="../Issues/iss278.htm">
|
|
<LINK REL=NEXT HREF="../Issues/iss279_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/iss277_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Previous]" SRC="../Graphics/Prev.gif" ALIGN=Bottom></A><A REL=UP HREF="../Issues/iss278.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Up]" SRC="../Graphics/Up.gif" ALIGN=Bottom></A><A REL=NEXT HREF="../Issues/iss279_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Next]" SRC="../Graphics/Next.gif" ALIGN=Bottom></A></H1>
|
|
|
|
<HR>
|
|
|
|
|
|
|
|
<H2>Issue PROCLAIM-ETC-IN-COMPILE-FILE Writeup</H2>
|
|
|
|
<PRE><B>Issue:</B> <A HREF="iss278.htm">PROCLAIM-ETC-IN-COMPILE-FILE</A><P>
|
|
<B>References:</B> CLtL p. 182 [package functions],<P>
|
|
p. 156 [PROCLAIM], p. 439 [COMPILE-FILE];<P>
|
|
Issue <A HREF="iss059.htm">COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS</A><P>
|
|
Issue <A HREF="iss195.htm">IN-PACKAGE-FUNCTIONALITY</A><P>
|
|
Issue <A HREF="iss147.htm">EVAL-WHEN-NON-TOP-LEVEL</A><P>
|
|
Issue <A HREF="iss104.htm">DEFINING-MACROS-NON-TOP-LEVEL</A><P>
|
|
<B>Category:</B> CLARIFICATION, CHANGE, ADDITION<P>
|
|
<B>Edit History:</B> 15 Sep 88, V1 by David Gray<P>
|
|
23 Sep 88, V2 by Sandra Loosemore (summarize discussion)<P>
|
|
11 Mar 89, V3 by Sandra Loosemore (rewrite)<P>
|
|
13 Mar 89, V4 by Sandra Loosemore (discussion)<P>
|
|
<B>Status:</B> **DRAFT**<P>
|
|
<P>
|
|
<P>
|
|
<B>Problem Description:<P>
|
|
</B><P>
|
|
Should the compiler treat top-level calls to <A REL=DEFINITION HREF="../Body/f_procla.htm#proclaim"><B>PROCLAIM</B></A> specially?<P>
|
|
<P>
|
|
Page 182 of CLtL says that <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A> needs to treat top-level calls<P>
|
|
to the following package functions as though they were wrapped in an<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_eval_w.htm#eval-when"><B>EVAL-WHEN</B></A> (<A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>COMPILE</B></A> <A REL=DEFINITION HREF="../Body/f_load.htm#load"><B>LOAD</B></A> <A REL=DEFINITION HREF="../Body/f_eval.htm#eval"><B>EVAL</B></A>) ...):<P>
|
|
<P>
|
|
<A REL=DEFINITION HREF="../Body/f_export.htm#export"><B>EXPORT</B></A> <A REL=DEFINITION HREF="../Body/f_import.htm#import"><B>IMPORT</B></A> <A REL=DEFINITION HREF="../Body/m_in_pkg.htm#in-package"><B>IN-PACKAGE</B></A> <A REL=DEFINITION HREF="../Body/f_mk_pkg.htm#make-package"><B>MAKE-PACKAGE</B></A> <A REL=DEFINITION HREF="../Body/f_shadow.htm#shadow"><B>SHADOW</B></A><P>
|
|
<A REL=DEFINITION HREF="../Body/f_shdw_i.htm#shadowing-import"><B>SHADOWING-IMPORT</B></A> <A REL=DEFINITION HREF="../Body/f_unexpo.htm#unexport"><B>UNEXPORT</B></A> <A REL=DEFINITION HREF="../Body/f_unuse_.htm#unuse-package"><B>UNUSE-PACKAGE</B></A> <A REL=DEFINITION HREF="../Body/f_use_pk.htm#use-package"><B>USE-PACKAGE</B></A><P>
|
|
<P>
|
|
CLtL is silent on whether top-level calls to <A REL=DEFINITION HREF="../Body/f_procla.htm#proclaim"><B>PROCLAIM</B></A> should also be<P>
|
|
evaluated at compile-time, which presumably means they shouldn't be.<P>
|
|
However, some implementations do evaluate <A REL=DEFINITION HREF="../Body/f_procla.htm#proclaim"><B>PROCLAIM</B></A> at compile-time.<P>
|
|
<P>
|
|
In the model of how <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A> works that is presented in issues<P>
|
|
<A HREF="iss147.htm">EVAL-WHEN-NON-TOP-LEVEL</A> and <A HREF="iss104.htm">DEFINING-MACROS-NON-TOP-LEVEL</A>, the special<P>
|
|
form <A REL=DEFINITION HREF="../Body/s_eval_w.htm#eval-when"><B>EVAL-WHEN</B></A> is the only thing that can cause compile-time evaluation<P>
|
|
to occur. The compile-time side-effects of macros such as <A REL=DEFINITION HREF="../Body/m_defmac.htm#defmacro"><B>DEFMACRO</B></A><P>
|
|
and <A REL=DEFINITION HREF="../Body/m_defpkg.htm#defpackage"><B>DEFPACKAGE</B></A> are explained by having them include <A REL=DEFINITION HREF="../Body/s_eval_w.htm#eval-when"><B>EVAL-WHEN</B></A> in their<P>
|
|
expansions. Any functions that are treated specially, however, must<P>
|
|
be included as special cases in the compiler.<P>
|
|
<P>
|
|
Proposal IN-PACKAGE-FUNCTIONALITY:NEW-MACRO would remove the<P>
|
|
requirement that the package functions be treated specially. Do we<P>
|
|
wish to make an exception to the model for PROCLAIM?<P>
|
|
<P>
|
|
<P>
|
|
<B>Proposal PROCLAIM-ETC-IN-COMPILE-FILE:YES:<P>
|
|
</B><P>
|
|
Require <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A> to treat top-level calls to <A REL=DEFINITION HREF="../Body/f_procla.htm#proclaim"><B>PROCLAIM</B></A> as if they<P>
|
|
were wrapped in an (<A REL=DEFINITION HREF="../Body/s_eval_w.htm#eval-when"><B>EVAL-WHEN</B></A> (<A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>COMPILE</B></A> <A REL=DEFINITION HREF="../Body/f_load.htm#load"><B>LOAD</B></A> <A REL=DEFINITION HREF="../Body/f_eval.htm#eval"><B>EVAL</B></A>) ...).<P>
|
|
<P>
|
|
Rationale:<P>
|
|
<P>
|
|
Proclamations affect compilation semantics and should be made <P>
|
|
available to the compiler.<P>
|
|
<P>
|
|
<P>
|
|
<B>Proposal PROCLAIM-ETC-IN-COMPILE-FILE:NO:<P>
|
|
</B><P>
|
|
Clarify that calls to <A REL=DEFINITION HREF="../Body/f_procla.htm#proclaim"><B>PROCLAIM</B></A> should be treated the same as any<P>
|
|
other function call. Users should wrap an explicit <A REL=DEFINITION HREF="../Body/s_eval_w.htm#eval-when"><B>EVAL-WHEN</B></A> around<P>
|
|
top-level calls to <A REL=DEFINITION HREF="../Body/f_procla.htm#proclaim"><B>PROCLAIM</B></A> if they want them to affect compilation.<P>
|
|
<P>
|
|
Rationale:<P>
|
|
<P>
|
|
This makes the semantics of <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A> more uniform and easier <P>
|
|
to understand. In particular, if we remove the magic compile-time<P>
|
|
behavior of the package functions, it seems silly to add another<P>
|
|
exception for <A REL=DEFINITION HREF="../Body/f_procla.htm#proclaim"><B>PROCLAIM</B></A>.<P>
|
|
<P>
|
|
<P>
|
|
<B>Proposal PROCLAIM-ETC-IN-COMPILE-FILE:NEW-MACRO:<P>
|
|
</B><P>
|
|
Add a new macro:<P>
|
|
<P>
|
|
DEFPROCLAIM &rest decl-specs [Macro]<P>
|
|
<P>
|
|
This macro PROCLAIMs the given <decl-specs>, which are not<P>
|
|
evaluated. If a call to this macro appears at top-level in a file<P>
|
|
being processed by the file compiler, the proclamations are also<P>
|
|
made at compile-time. As with other defining macros, it is <P>
|
|
unspecified whether or not the compile-time side-effects of a <P>
|
|
DEFPROCLAIM persist after the file has been compiled.<P>
|
|
<P>
|
|
Clarify that calls to <A REL=DEFINITION HREF="../Body/f_procla.htm#proclaim"><B>PROCLAIM</B></A> should be treated the same as any<P>
|
|
other function call. Users should wrap an explicit <A REL=DEFINITION HREF="../Body/s_eval_w.htm#eval-when"><B>EVAL-WHEN</B></A> around<P>
|
|
top-level calls to <A REL=DEFINITION HREF="../Body/f_procla.htm#proclaim"><B>PROCLAIM</B></A> if they want them to affect compilation,<P>
|
|
or use the macro DEFPROCLAIM.<P>
|
|
<P>
|
|
Rationale:<P>
|
|
<P>
|
|
The macro makes the proclamations available to the compiler in such<P>
|
|
a way that does not <A REL=DEFINITION HREF="../Body/f_provid.htm#require"><B>require</B></A> any special exceptions to be made in<P>
|
|
the model of how <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A> works.<P>
|
|
<P>
|
|
<B>Current Practice:<P>
|
|
</B><P>
|
|
The TI explorer apparently implements proposal YES, except that<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_eval_w.htm#eval-when"><B>EVAL-WHEN</B></A> (<A REL=DEFINITION HREF="../Body/f_load.htm#load"><B>LOAD</B></A>) (<A REL=DEFINITION HREF="../Body/f_procla.htm#proclaim"><B>PROCLAIM</B></A> '(<A REL=DEFINITION HREF="../Body/d_optimi.htm#optimize"><B>OPTIMIZE</B></A> ...))) doesn't do anything.<P>
|
|
The Symbolics compiler has special top-level handling for <A REL=DEFINITION HREF="../Body/f_procla.htm#proclaim"><B>PROCLAIM</B></A>,<P>
|
|
although the details are not clear.<P>
|
|
<P>
|
|
Lisps developed at Utah (UCL, A-Lisp, PSL/PCLS) do not give <A REL=DEFINITION HREF="../Body/f_procla.htm#proclaim"><B>PROCLAIM</B></A><P>
|
|
any special compile-time handling.<P>
|
|
<P>
|
|
Lucid does not evaluate calls to <A REL=DEFINITION HREF="../Body/f_procla.htm#proclaim"><B>PROCLAIM</B></A> at compile-time.<P>
|
|
<P>
|
|
The IIM compiler has special top-level handling for <A REL=DEFINITION HREF="../Body/f_procla.htm#proclaim"><B>PROCLAIM</B></A> when<P>
|
|
the argument is a constant. The information is recorded in the remote<P>
|
|
environment.<P>
|
|
<P>
|
|
<B>Cost to implementors:<P>
|
|
</B><P>
|
|
Since implementations are already required to have a mechanism for<P>
|
|
compile-time handling of the package functions, it would probably<P>
|
|
only <A REL=DEFINITION HREF="../Body/f_provid.htm#require"><B>require</B></A> minor adjustments to add handling for <A REL=DEFINITION HREF="../Body/f_procla.htm#proclaim"><B>PROCLAIM</B></A>.<P>
|
|
<P>
|
|
<B>Cost to users:<P>
|
|
</B><P>
|
|
For proposal YES, users would have no way to suppress compile-time<P>
|
|
evaluation of a top-level call to <A REL=DEFINITION HREF="../Body/f_procla.htm#proclaim"><B>PROCLAIM</B></A>. Wrapping it in an<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_eval_w.htm#eval-when"><B>EVAL-WHEN</B></A> (<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>)...) wouldn't work under the model of how<P>
|
|
<A REL=DEFINITION HREF="../Body/s_eval_w.htm#eval-when"><B>EVAL-WHEN</B></A> works in proposal EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL.<P>
|
|
<P>
|
|
Under any of these proposals, some users would probably have to<P>
|
|
make minor changes to their code.<P>
|
|
<P>
|
|
<B>Benefits:<P>
|
|
</B><P>
|
|
Users will know what to expect when they use <A REL=DEFINITION HREF="../Body/f_procla.htm#proclaim"><B>PROCLAIM</B></A>.<P>
|
|
<P>
|
|
<B>Costs of Non-Adoption: <P>
|
|
</B><P>
|
|
Users will not know what to expect when they use <A REL=DEFINITION HREF="../Body/f_procla.htm#proclaim"><B>PROCLAIM</B></A>.<P>
|
|
<P>
|
|
<B>Aesthetics:<P>
|
|
</B><P>
|
|
At least two people consider requiring magic behavior for certain<P>
|
|
top-level function calls to be "semantically bletcherous". Removing<P>
|
|
all special cases for functions that are implicitly evaluated at<P>
|
|
compile-time would simplify the model of how <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A> works.<P>
|
|
<P>
|
|
Programs look cleaner if <A REL=DEFINITION HREF="../Body/s_eval_w.htm#eval-when"><B>EVAL-WHEN</B></A> is only needed for unusual cases<P>
|
|
instead of being required for the normal cases.<P>
|
|
<P>
|
|
<B>Discussion:<P>
|
|
</B><P>
|
|
The first version of this writeup also included <A REL=DEFINITION HREF="../Body/f_provid.htm#require"><B>REQUIRE</B></A> with <A REL=DEFINITION HREF="../Body/f_procla.htm#proclaim"><B>PROCLAIM</B></A>,<P>
|
|
but we have now voted to remove <A REL=DEFINITION HREF="../Body/f_provid.htm#require"><B>REQUIRE</B></A> from the language entirely.<P>
|
|
It also specified that <A REL=DEFINITION HREF="../Body/d_optimi.htm#optimize"><B>OPTIMIZE</B></A> proclamations should only have a local<P>
|
|
effect within the file being compiled. This was removed for <P>
|
|
consistency with other compile-time side-effects (such as those from<P>
|
|
<A REL=DEFINITION HREF="../Body/m_defmac.htm#defmacro"><B>DEFMACRO</B></A>), where their persistence is explicitly left unspecified.<P>
|
|
<P>
|
|
Loosemore favors proposal NO, but wouldn't oppose proposal NEW-MACRO.<P>
|
|
<P>
|
|
Kim Barrett says:<P>
|
|
<P>
|
|
Proposal YES violates the general approach we've been taking of trying<P>
|
|
to limit side-effects on the local environment during compilation.<P>
|
|
<P>
|
|
Proposal NO makes <A REL=DEFINITION HREF="../Body/f_procla.htm#proclaim"><B>PROCLAIM</B></A> virtually worthless.<P>
|
|
<P>
|
|
Proposal NEW-MACRO -- While this matches up with other stuff we've<P>
|
|
been doing, I'm concerned about two things. First, I really dislike<P>
|
|
the name DEFPROCLAIM. This thing isn't defining anything! It sounds<P>
|
|
like something that modifies the behavior of <A REL=DEFINITION HREF="../Body/f_procla.htm#proclaim"><B>PROCLAIM</B></A>, not something<P>
|
|
that actually makes a proclamation. Second, I'm concerned about the<P>
|
|
cost to users. I think the statement that<P>
|
|
<P>
|
|
"Under any of these proposals, some users would probably have to make <P>
|
|
minor changes to their code."<P>
|
|
<P>
|
|
is rather misleading for this case. There are a lot of PROCLAIMs out<P>
|
|
there.<P>
|
|
<P>
|
|
Loosemore replies:<P>
|
|
<P>
|
|
....but all of those uses of <A REL=DEFINITION HREF="../Body/f_procla.htm#proclaim"><B>PROCLAIM</B></A> are already nonportable. No<P>
|
|
matter what we do here, somebody is going to get burned.<P>
|
|
<P>
|
|
Suggestions for better names for the macro are welcome.<P>
|
|
<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>
|