257 lines
18 KiB
HTML
257 lines
18 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 QUOTE-SEMANTICS 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/iss281_w.htm">
|
|
<LINK REL=UP HREF="../Issues/iss282.htm">
|
|
<LINK REL=NEXT HREF="../Issues/iss283_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/iss281_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Previous]" SRC="../Graphics/Prev.gif" ALIGN=Bottom></A><A REL=UP HREF="../Issues/iss282.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Up]" SRC="../Graphics/Up.gif" ALIGN=Bottom></A><A REL=NEXT HREF="../Issues/iss283_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Next]" SRC="../Graphics/Next.gif" ALIGN=Bottom></A></H1>
|
|
|
|
<HR>
|
|
|
|
|
|
|
|
<H2>Issue QUOTE-SEMANTICS Writeup</H2>
|
|
|
|
<PRE><B>Forum:</B> Compiler<P>
|
|
<B>Issue:</B> <A HREF="iss282.htm">QUOTE-SEMANTICS</A><P>
|
|
Subsumes: Issue QUOTE-MAY-COPY<P>
|
|
<B>References:</B> CLtL p. 55, 78, 86, 143<P>
|
|
Issue <A HREF="iss080.htm">CONSTANT-COLLAPSING</A><P>
|
|
Issue <A HREF="iss081.htm">CONSTANT-COMPILABLE-TYPES</A><P>
|
|
Issue <A HREF="iss079.htm">CONSTANT-CIRCULAR-COMPILATION</A><P>
|
|
<B>Category:</B> CLARIFICATION<P>
|
|
<B>Edit History:</B> V1, 22 Jan 1989, Sandra Loosemore<P>
|
|
V2, 13 Mar 1989, Sandra Loosemore (discussion)<P>
|
|
V3, 22 Mar 1989, Sandra Loosemore (suggestions from Moon)<P>
|
|
<B>Status:</B> Ready for release<P>
|
|
<P>
|
|
<P>
|
|
<B>Problem Description:<P>
|
|
</B><P>
|
|
Is it permissible for <A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>COMPILE</B></A> and <A REL=DEFINITION HREF="../Body/f_eval.htm#eval"><B>EVAL</B></A> to coalesce or copy constants?<P>
|
|
Are there constraints upon what kinds of objects may appear as<P>
|
|
constants in code processed by <A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>COMPILE</B></A> or <A REL=DEFINITION HREF="../Body/f_eval.htm#eval"><B>EVAL</B></A>, similar to those for<P>
|
|
COMPILE-FILE?<P>
|
|
<P>
|
|
CLtL p86 states that (<A REL=DEFINITION HREF="../Body/s_quote.htm#quote"><B>QUOTE</B></A> <x>) simply returns <x>. On p55 it is<P>
|
|
mentioned that the only self-evaluating forms that may be copied are<P>
|
|
numbers or characters. It is also stated that an implementation is<P>
|
|
permitted to collapse (or coalesce) <A REL=DEFINITION HREF="../Body/f_equal.htm#equal"><B>EQUAL</B></A> constants "appearing in code<P>
|
|
to be compiled" (p78), which is defined to mean self-evaluating forms<P>
|
|
or objects contained in a <A REL=DEFINITION HREF="../Body/s_quote.htm#quote"><B>QUOTE</B></A> form (without reference to whether the<P>
|
|
form is processed by <A REL=DEFINITION HREF="../Body/f_eval.htm#eval"><B>EVAL</B></A>, <A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>COMPILE</B></A>, or <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A>).<P>
|
|
<P>
|
|
Because of its nature as a file processor, <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A> generally must<P>
|
|
cause copies of constants to be constructed when the compiled code is<P>
|
|
loaded. In a number of existing Lisp implementations, <A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>COMPILE</B></A> also<P>
|
|
causes constant objects to be copied and/or coalesced. There is also<P>
|
|
at least one implementation where constants are copied by <A REL=DEFINITION HREF="../Body/f_eval.htm#eval"><B>EVAL</B></A> in some<P>
|
|
circumstances.<P>
|
|
<P>
|
|
In the proposals that follow, "copying" is used to mean the process of<P>
|
|
constructing an object that is "similar as a constant" (as defined in<P>
|
|
proposal <A HREF="iss081.htm">CONSTANT-COMPILABLE-TYPES:SPECIFY</A>), but not necessarily <A REL=DEFINITION HREF="../Body/a_eql.htm#eql"><B>EQL</B></A>,<P>
|
|
to the original.<P>
|
|
<P>
|
|
The term "coalescing" is defined in the writeup for issue <P>
|
|
<A HREF="iss080.htm">CONSTANT-COLLAPSING</A>.<P>
|
|
<P>
|
|
<P>
|
|
<B>Proposal QUOTE-SEMANTICS:NO-COPYING:<P>
|
|
</B><P>
|
|
State that copying or coalescing of constants appearing in code<P>
|
|
processed by <A REL=DEFINITION HREF="../Body/f_eval.htm#eval"><B>EVAL</B></A> and <A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>COMPILE</B></A> is not permitted; the resulting program<P>
|
|
must reference objects that are <A REL=DEFINITION HREF="../Body/a_eql.htm#eql"><B>EQL</B></A> to the corresponding objects in<P>
|
|
the source code. The constraints on what kinds of objects may appear<P>
|
|
as constants (described in issues <A HREF="iss081.htm">CONSTANT-COMPILABLE-TYPES</A> and<P>
|
|
<A HREF="iss079.htm">CONSTANT-CIRCULAR-COMPILATION</A>) apply only to <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A>.<P>
|
|
<P>
|
|
Rationale:<P>
|
|
<P>
|
|
This proposal is consistent with what many people think of as the<P>
|
|
"traditional" semantics for <A REL=DEFINITION HREF="../Body/s_quote.htm#quote"><B>QUOTE</B></A>. It gives users maximum flexibility<P>
|
|
about what kinds of objects may appear as constants.<P>
|
|
<P>
|
|
<P>
|
|
<B>Proposal QUOTE-SEMANTICS:COPYING-ALLOWED-BUT-NO-CONSTRAINTS:<P>
|
|
</B><P>
|
|
State that copying or coalescing of constants appearing in code<P>
|
|
processed by <A REL=DEFINITION HREF="../Body/f_eval.htm#eval"><B>EVAL</B></A> and <A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>COMPILE</B></A> is permitted. Copying or coalescing may<P>
|
|
only take place when the source code is "promoted" to being a program<P>
|
|
by <A REL=DEFINITION HREF="../Body/f_eval.htm#eval"><B>EVAL</B></A> or <A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>COMPILE</B></A>, not at runtime. Function definitions are promoted<P>
|
|
to being a program when the form enclosing the definition (e.g., a<P>
|
|
<A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A> or <A REL=DEFINITION HREF="../Body/m_defun.htm#defun"><B>DEFUN</B></A> form) is promoted.<P>
|
|
<P>
|
|
Any object may validly appear as a constant in code processed by <A REL=DEFINITION HREF="../Body/f_eval.htm#eval"><B>EVAL</B></A><P>
|
|
or <A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>COMPILE</B></A>. The constraints on what kinds of objects may appear as<P>
|
|
constants (described in issues <A HREF="iss081.htm">CONSTANT-COMPILABLE-TYPES</A> and<P>
|
|
<A HREF="iss079.htm">CONSTANT-CIRCULAR-COMPILATION</A>) apply only to <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A>. For data<P>
|
|
types where proposal <A HREF="iss081.htm">CONSTANT-COMPILABLE-TYPES:SPECIFY</A> does not define<P>
|
|
the notion of "similar as a constant", an implementation is permitted<P>
|
|
to copy objects of that type only if it has extended "similar as a<P>
|
|
constant" to include that type.<P>
|
|
<P>
|
|
Rationale:<P>
|
|
<P>
|
|
This proposal is the most consistent with the semantics stated in CLtL.<P>
|
|
It gives users maximum flexibility about what kinds of objects may<P>
|
|
appear as constants.<P>
|
|
<P>
|
|
Allowing constants to be coalesced or copied has advantages for<P>
|
|
memory management; for example, constants can be copied to read-only<P>
|
|
memory that does not need to be garbage-collected.<P>
|
|
<P>
|
|
<P>
|
|
<B>Proposal QUOTE-SEMANTICS:SAME-AS-COMPILE-FILE:<P>
|
|
</B><P>
|
|
State that copying or coalescing of constants appearing in code<P>
|
|
processed by <A REL=DEFINITION HREF="../Body/f_eval.htm#eval"><B>EVAL</B></A> and <A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>COMPILE</B></A> is permitted. Copying or coalescing may<P>
|
|
only take place when the source code is "promoted" to being a program<P>
|
|
by <A REL=DEFINITION HREF="../Body/f_eval.htm#eval"><B>EVAL</B></A> or <A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>COMPILE</B></A>, not at runtime. Function definitions are promoted<P>
|
|
to being a program when the form enclosing the definition (e.g., a<P>
|
|
<A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A> or <A REL=DEFINITION HREF="../Body/m_defun.htm#defun"><B>DEFUN</B></A> form) is promoted.<P>
|
|
<P>
|
|
The constraints on what kinds of objects may appear as constants<P>
|
|
(described in issues <A HREF="iss081.htm">CONSTANT-COMPILABLE-TYPES</A> <A REL=DEFINITION HREF="../Body/a_and.htm#and"><B>and</B></A><P>
|
|
<A HREF="iss079.htm">CONSTANT-CIRCULAR-COMPILATION</A>) apply to <A REL=DEFINITION HREF="../Body/f_eval.htm#eval"><B>EVAL</B></A> and <A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>COMPILE</B></A> as well as to<P>
|
|
<A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A>.<P>
|
|
<P>
|
|
Rationale:<P>
|
|
<P>
|
|
This makes the rules for handling of constants consistent between<P>
|
|
<A REL=DEFINITION HREF="../Body/f_eval.htm#eval"><B>EVAL</B></A>, <A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>COMPILE</B></A>, and <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A>. It gives implementors maximum <P>
|
|
flexibility in handling constants in <A REL=DEFINITION HREF="../Body/f_eval.htm#eval"><B>EVAL</B></A> and <A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>COMPILE</B></A>.<P>
|
|
<P>
|
|
Allowing constants to be coalesced or copied has advantages for<P>
|
|
memory management; for example, constants can be copied to read-only<P>
|
|
memory that does not need to be garbage-collected.<P>
|
|
<P>
|
|
<P>
|
|
<B>Current Practice:<P>
|
|
</B><P>
|
|
Implementations in which <A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>COMPILE</B></A> attempts to copy all constants<P>
|
|
include PSL/PCLS, Utah Common Lisp, and Kyoto Common Lisp. UCL and<P>
|
|
KCL both implement <A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>COMPILE</B></A> effectively as a combination of<P>
|
|
<A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A> and <A REL=DEFINITION HREF="../Body/f_load.htm#load"><B>LOAD</B></A>.<P>
|
|
<P>
|
|
In Lucid Common Lisp, constants are not normally copied by <A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>COMPILE</B></A>,<P>
|
|
but since <A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>COMPILE</B></A> does coalesce constants, it may cause <A REL=DEFINITION HREF="../Body/s_quote.htm#quote"><B>QUOTE</B></A> to<P>
|
|
return an object which is not <A REL=DEFINITION HREF="../Body/a_eql.htm#eql"><B>EQL</B></A> to the object which appeared in the<P>
|
|
source code.<P>
|
|
<P>
|
|
Symbolics Genera has <A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>COMPILE</B></A> copy list, string, non-displaced array,<P>
|
|
and (I-Machine only) closure constants, but Moon says he thinks this<P>
|
|
is wrong.<P>
|
|
<P>
|
|
There is known to be at least one implementation where expanding the<P>
|
|
<A REL=DEFINITION HREF="../Body/m_defun.htm#defun"><B>DEFUN</B></A> macro causes all constants in the body of the function to be<P>
|
|
copied.<P>
|
|
<P>
|
|
<P>
|
|
<B>Cost to implementors:<P>
|
|
</B><P>
|
|
Proposal NO-COPYING would involve a significant cost in those<P>
|
|
implementations where constants are now copied or coalesced by <A REL=DEFINITION HREF="../Body/f_eval.htm#eval"><B>EVAL</B></A><P>
|
|
and <A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>COMPILE</B></A>. The aspect that is likely to cause the most problems is<P>
|
|
that, in some implementations, the garbage collector assumes that<P>
|
|
constants referenced in compiled code have been copied to read-only<P>
|
|
storage and do not need to be scanned or relocated. Changing this<P>
|
|
would <A REL=DEFINITION HREF="../Body/f_provid.htm#require"><B>require</B></A> major changes to the internal representation of<P>
|
|
functions, memory management strategy, and/or the implementation of<P>
|
|
<A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>COMPILE</B></A>.<P>
|
|
<P>
|
|
Some implementations would also <A REL=DEFINITION HREF="../Body/f_provid.htm#require"><B>require</B></A> substantial changes to support<P>
|
|
proposal COPYING-ALLOWED-BUT-NO-CONSTRAINTS. Implementations that<P>
|
|
would have garbage collection problems under proposal NO-COPYING would<P>
|
|
have the same problems under COPYING-ALLOWED-BUT-NO-CONSTRAINTS,<P>
|
|
unless they can define a copying behavior that will correctly handle<P>
|
|
objects of all possible datatypes.<P>
|
|
<P>
|
|
Proposal SAME-AS-COMPILE-FILE has no adoption cost above what is<P>
|
|
required to support issues <A HREF="iss081.htm">CONSTANT-COMPILABLE-TYPES</A> and<P>
|
|
<A HREF="iss079.htm">CONSTANT-CIRCULAR-COMPILATION</A>.<P>
|
|
<P>
|
|
<P>
|
|
<B>Cost to users:<P>
|
|
</B><P>
|
|
Proposals COPYING-ALLOWED-BUT-NO-CONSTRAINTS and SAME-AS-COMPILE-FILE<P>
|
|
may break some existing programs that assume constants in code<P>
|
|
processed by <A REL=DEFINITION HREF="../Body/f_eval.htm#eval"><B>EVAL</B></A> or <A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>COMPILE</B></A> are always <A REL=DEFINITION HREF="../Body/a_eql.htm#eql"><B>EQL</B></A> to the corresponding<P>
|
|
objects in the source code. Proposal SAME-AS-COMPILE-FILE may also<P>
|
|
break existing programs that depend on referencing "undumpable"<P>
|
|
constants in code processed by <A REL=DEFINITION HREF="../Body/f_eval.htm#eval"><B>EVAL</B></A> or <A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>COMPILE</B></A>. In both cases,<P>
|
|
however, the behavior is already nonportable. Both proposals would<P>
|
|
permit implementations in which these programs now work to continue to<P>
|
|
<A REL=DEFINITION HREF="../Body/f_provid.htm#provide"><B>provide</B></A> their existing behavior.<P>
|
|
<P>
|
|
<P>
|
|
<B>Benefits:<P>
|
|
</B><P>
|
|
The semantics of <A REL=DEFINITION HREF="../Body/s_quote.htm#quote"><B>QUOTE</B></A> are clarified.<P>
|
|
<P>
|
|
<P>
|
|
<B>Discussion:<P>
|
|
</B><P>
|
|
This issue subsumes issue QUOTE-MAY-COPY, which caused a very lengthy<P>
|
|
debate on the cl-compiler mailing list.<P>
|
|
<P>
|
|
This issue relates to conformance requirements. Accepting either of<P>
|
|
proposals NO-COPYING or COPYING-ALLOWED-BUT-NO-CONSTRAINTS would mean<P>
|
|
that not all conforming programs could be compiled with <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A>.<P>
|
|
Some people may find this disturbing, particularly since one of the<P>
|
|
goals of Common Lisp has been to try to eliminate differences in<P>
|
|
semantics between compiled and interpreted code.<P>
|
|
<P>
|
|
Loosemore supports proposal QUOTE-SEMANTICS:SAME-AS-COMPILE-FILE,<P>
|
|
since it requires essentially no conversion cost for implementors and<P>
|
|
does not break any user programs that are not already nonportable.<P>
|
|
<P>
|
|
JonL White says:<P>
|
|
Since we have already passed the proposal that permits constants to <P>
|
|
be "read-only" -- it is an error to modify them -- and have already <P>
|
|
passed the proposal that allows access to updateable structures -- <P>
|
|
<A HREF="iss216_m.htm">LOAD-TIME-EVAL</A> -- then there is no excuse for being overly concerned<P>
|
|
with the storage address of quoted data. People who have mistakenly <P>
|
|
used structured constants as updatable data should convert over to <P>
|
|
either <A HREF="iss216_m.htm">LOAD-TIME-EVAL</A> or <A REL=DEFINITION HREF="../Body/m_defpar.htm#defparameter"><B>DEFPARAMETER</B></A>.<P>
|
|
<P>
|
|
Kent Pitman says:<P>
|
|
The problem is that a lot of copying advocates have been going around<P>
|
|
trying to use "the need for copying" as leverage for restricting<P>
|
|
the set of things which I may quote. My view is that it is my write [sic]<P>
|
|
to quote whatever I want, and it's up to the person who thinks they<P>
|
|
can do something fun with copying to not get themselves in deeper than<P>
|
|
they can handle.<P>
|
|
<P>
|
|
Jeff Dalton says: <P>
|
|
I would agree [with Pitman's remarks] too. My only quibble is that<P>
|
|
it's not just "the need for copying" that's used a lever.<P>
|
|
"Consistency with file compilation" is also being used as a lever.<P>
|
|
<P>
|
|
UCL implements <A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>COMPILE</B></A> by dumping and loading a temporary file using<P>
|
|
the same mechanisms as <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A> and <A REL=DEFINITION HREF="../Body/f_load.htm#load"><B>LOAD</B></A>. Leigh Stoller (one of<P>
|
|
the UCL compiler implementors) says that, even if this implementation<P>
|
|
technique is disallowed by the outcome of this issue, they would<P>
|
|
rather be nonconforming than change the implementation of <A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>COMPILE</B></A>. In<P>
|
|
addition to the change being a lot of work, he says he thinks that<P>
|
|
making <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A> and <A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>COMPILE</B></A> different would be "really dumb", and<P>
|
|
that having different conformance requirements for compiled and<P>
|
|
interpreted code would just encourage people to write programs that<P>
|
|
can't be compiled correctly.<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>
|