278 lines
17 KiB
HTML
278 lines
17 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 COMPILE-FILE-SYMBOL-HANDLING 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/iss062_w.htm">
|
|
<LINK REL=UP HREF="../Issues/iss063.htm">
|
|
<LINK REL=NEXT HREF="../Issues/iss064_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/iss062_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Previous]" SRC="../Graphics/Prev.gif" ALIGN=Bottom></A><A REL=UP HREF="../Issues/iss063.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Up]" SRC="../Graphics/Up.gif" ALIGN=Bottom></A><A REL=NEXT HREF="../Issues/iss064_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Next]" SRC="../Graphics/Next.gif" ALIGN=Bottom></A></H1>
|
|
|
|
<HR>
|
|
|
|
|
|
|
|
<H2>Issue COMPILE-FILE-SYMBOL-HANDLING Writeup</H2>
|
|
|
|
<PRE><B>Forum:</B> Compiler<P>
|
|
<B>Issue:</B> <A HREF="iss063.htm">COMPILE-FILE-SYMBOL-HANDLING</A><P>
|
|
<B>References:</B> CLtL p. 182<P>
|
|
Issue <A HREF="iss195.htm">IN-PACKAGE-FUNCTIONALITY</A> (passed)<P>
|
|
Issue <A HREF="iss081.htm">CONSTANT-COMPILABLE-TYPES</A> (passed)<P>
|
|
Issue <A REL=DEFINITION HREF="../Body/m_defpkg.htm#defpackage"><B>DEFPACKAGE</B></A> (passed)<P>
|
|
<B>Category:</B> CHANGE/CLARIFICATION <P>
|
|
<B>Edit History:</B> V1, 01 Feb 1989, Sandra Loosemore<P>
|
|
V2, 12 Mar 1989, Sandra Loosemore (discussion, error terms)<P>
|
|
V3, 18 Apr 1989, Sandra Loosemore (new proposal)<P>
|
|
V4, 15 Jun 1989, Sandra Loosemore (minor wording changes)<P>
|
|
V5, 04 Jul 1989, Sandra Loosemore (incorporate amendments)<P>
|
|
<B>Status:</B> Passed, as amended, June 89<P>
|
|
Recommendation to drafting committee: in item 1b, clarify<P>
|
|
that the "first" top-level form may appear as the first<P>
|
|
form inside a top-level <A REL=DEFINITION HREF="../Body/s_progn.htm#progn"><B>PROGN</B></A>, as the result of macro<P>
|
|
expansion, etc.<P>
|
|
<P>
|
|
<P>
|
|
<P>
|
|
<B>Problem Description:<P>
|
|
</B><P>
|
|
It is not clear how <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A> is supposed to specify to <A REL=DEFINITION HREF="../Body/f_load.htm#load"><B>LOAD</B></A> how<P>
|
|
symbols in the compiled file should be interned. In particular, what<P>
|
|
happens if the value of <A REL=DEFINITION HREF="../Body/v_pkg.htm#STpackageST"><B>*PACKAGE*</B></A> is different at load-time than it<P>
|
|
was at compile-time, or if any of the packages referenced in the file<P>
|
|
are defined differently?<P>
|
|
<P>
|
|
There are two models currently being used to implement this behavior:<P>
|
|
<P>
|
|
(1) Symbols appearing in the output file produced by <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A><P>
|
|
are qualified with package prefixes in the same way that <A REL=DEFINITION HREF="../Body/f_wr_pr.htm#print"><B>PRINT</B></A><P>
|
|
would qualify them. Symbols that are accessible in <A REL=DEFINITION HREF="../Body/v_pkg.htm#STpackageST"><B>*PACKAGE*</B></A><P>
|
|
at compile-time are looked up in <A REL=DEFINITION HREF="../Body/v_pkg.htm#STpackageST"><B>*PACKAGE*</B></A> at load-time. (This<P>
|
|
is the "current-package" model.)<P>
|
|
<P>
|
|
(2) Symbols appearing in the output file produced by <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A><P>
|
|
are always qualified with the name of their home package,<P>
|
|
regardless of the value of <A REL=DEFINITION HREF="../Body/v_pkg.htm#STpackageST"><B>*PACKAGE*</B></A>. (This is the<P>
|
|
"home-package" model.)<P>
|
|
<P>
|
|
<P>
|
|
<B>Proposal COMPILE-FILE-SYMBOL-HANDLING:NEW-REQUIRE-CONSISTENCY:<P>
|
|
</B><P>
|
|
In order to guarantee that compiled files can be loaded correctly,<P>
|
|
users must ensure that the packages referenced in the file are defined<P>
|
|
consistently at compile and load time. Conforming Common Lisp programs<P>
|
|
must satisfy the following requirements:<P>
|
|
<P>
|
|
(1) The value of <A REL=DEFINITION HREF="../Body/v_pkg.htm#STpackageST"><B>*PACKAGE*</B></A> when a top-level form in the file is processed<P>
|
|
by <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A> must be the same as the value of <A REL=DEFINITION HREF="../Body/v_pkg.htm#STpackageST"><B>*PACKAGE*</B></A> when the<P>
|
|
code corresponding to that top-level form in the compiled file is<P>
|
|
executed by the loader. In particular:<P>
|
|
<P>
|
|
(a) Any top-level form in a file which alters the value of <A REL=DEFINITION HREF="../Body/v_pkg.htm#STpackageST"><B>*PACKAGE*</B></A><P>
|
|
must change it to a package of the same name at both compile and<P>
|
|
load time.<P>
|
|
<P>
|
|
(b) If the first nonatomic top-level form in the file is not a call to<P>
|
|
<A REL=DEFINITION HREF="../Body/m_in_pkg.htm#in-package"><B>IN-PACKAGE</B></A>, then the value of <A REL=DEFINITION HREF="../Body/v_pkg.htm#STpackageST"><B>*PACKAGE*</B></A> at the time <A REL=DEFINITION HREF="../Body/f_load.htm#load"><B>LOAD</B></A> is<P>
|
|
called must be a package with the same name as the package that<P>
|
|
was the value of <A REL=DEFINITION HREF="../Body/v_pkg.htm#STpackageST"><B>*PACKAGE*</B></A> at the time <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A> was called.<P>
|
|
<P>
|
|
(2) For all symbols appearing lexically within a top-level form that<P>
|
|
were accessible in the package that was the value of <A REL=DEFINITION HREF="../Body/v_pkg.htm#STpackageST"><B>*PACKAGE*</B></A><P>
|
|
during processing of that top-level form at compile time, but<P>
|
|
whose home package was another package, at load time there must<P>
|
|
be a symbol with the same name that is accessible in both the<P>
|
|
load-time <A REL=DEFINITION HREF="../Body/v_pkg.htm#STpackageST"><B>*PACKAGE*</B></A> and in the package with the same name as the<P>
|
|
compile-time home package. <P>
|
|
<P>
|
|
(3) For all symbols in the compiled file that were external symbols in<P>
|
|
their home package at compile time, there must be a symbol with the<P>
|
|
same name that is an external symbol in the package with the same name<P>
|
|
at load time.<P>
|
|
<P>
|
|
If any of these conditions do not hold, the package in which <A REL=DEFINITION HREF="../Body/f_load.htm#load"><B>LOAD</B></A> looks<P>
|
|
for the affected symbols is unspecified. Implementations are permitted <P>
|
|
to signal an error or otherwise define this behavior.<P>
|
|
<P>
|
|
A symbol S appearing in the source code is similar as a constant to <P>
|
|
a symbol S' in the compiled code if:<P>
|
|
<P>
|
|
o Their print names are similar as constants<P>
|
|
<P>
|
|
And, either<P>
|
|
<P>
|
|
o S is accessible in <A REL=DEFINITION HREF="../Body/v_pkg.htm#STpackageST"><B>*PACKAGE*</B></A> at compile time, and S' is accessible in<P>
|
|
<A REL=DEFINITION HREF="../Body/v_pkg.htm#STpackageST"><B>*PACKAGE*</B></A> at load time<P>
|
|
<P>
|
|
Or<P>
|
|
<P>
|
|
o S' is accessible in the package that is similar as a constant to the<P>
|
|
home package of symbol S.<P>
|
|
<P>
|
|
The "similar as constants" relationship for interned symbols has nothing<P>
|
|
to do with <A REL=DEFINITION HREF="../Body/v_rdtabl.htm#STreadtableST"><B>*READTABLE*</B></A> or how the function <A REL=DEFINITION HREF="../Body/f_rd_rd.htm#read"><B>READ</B></A> would parse the <P>
|
|
characters in the print name of the symbol.<P>
|
|
<P>
|
|
<P>
|
|
Rationale:<P>
|
|
<P>
|
|
This proposal is merely an explicit statement of the status quo,<P>
|
|
namely that users cannot depend on any particular behavior if the<P>
|
|
package environment at load time is inconsistent with what existed<P>
|
|
at compile time. <P>
|
|
<P>
|
|
This proposal supports both the current-package and home-package<P>
|
|
models as implementation techniques. <P>
|
|
<P>
|
|
<B>Current Practice:<P>
|
|
</B><P>
|
|
PSL/PCLS implements the home-package model, as does A-Lisp. Utah<P>
|
|
Common Lisp implements the current-package model, but the chief<P>
|
|
compiler hacker says he thinks that the home-package model<P>
|
|
actually makes more sense, and agrees that any program that behaves<P>
|
|
differently under the two proposals is broken. <P>
|
|
<P>
|
|
The TI Explorer currently implements the home-package model, after<P>
|
|
trying it both ways.<P>
|
|
<P>
|
|
KCL also implements the home-package model.<P>
|
|
<P>
|
|
Lucid Lisp appears to implement the current-package model.<P>
|
|
<P>
|
|
Symbolics Genera implements the current-package model. Symbolics<P>
|
|
Cloe probably does also.<P>
|
|
<P>
|
|
Coral also implements the current-package model.<P>
|
|
<P>
|
|
<P>
|
|
<B>Cost to implementors:<P>
|
|
</B><P>
|
|
Proposal NEW-REQUIRE-CONSISTENCY is intended to be compatible with either<P>
|
|
of the two models, but it may not be entirely compatible with the <P>
|
|
details of current implementations.<P>
|
|
<P>
|
|
In particular, some implementations that use the current-package<P>
|
|
model appear to restrict <A REL=DEFINITION HREF="../Body/m_in_pkg.htm#in-package"><B>IN-PACKAGE</B></A> to being the first top-level<P>
|
|
form in the file and dump all symbols referenced in the file after<P>
|
|
the entire file has been processed (so that the value of <A REL=DEFINITION HREF="../Body/v_pkg.htm#STpackageST"><B>*PACKAGE*</B></A><P>
|
|
used to determine whether to qualify symbols in the output file is<P>
|
|
the same for all symbols in the file). Under this proposal, these<P>
|
|
implementations would have to note when the value of <A REL=DEFINITION HREF="../Body/v_pkg.htm#STpackageST"><B>*PACKAGE*</B></A><P>
|
|
changes during processing of a top-level form.<P>
|
|
<P>
|
|
<P>
|
|
<B>Cost to users:<P>
|
|
</B><P>
|
|
Any user program that would break under proposal NEW-REQUIRE-CONSISTENCY<P>
|
|
is probably already nonportable, since this proposal is intended to<P>
|
|
leave the behavior unspecified where it would differ under the<P>
|
|
two implementation models.<P>
|
|
<P>
|
|
For a discussion of how the two models treat nonportable or erroneous<P>
|
|
programs, see the "Analysis" section below.<P>
|
|
<P>
|
|
<P>
|
|
<B>Benefits:<P>
|
|
</B><P>
|
|
<A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A>'s treatment of symbols is made explicit in the <A REL=DEFINITION HREF="../Body/07_ffb.htm#standard"><B>standard</B></A>.<P>
|
|
<P>
|
|
<P>
|
|
<B>Analysis:<P>
|
|
</B><P>
|
|
The two implementation models differ in the following situations.<P>
|
|
Proposal NEW-REQUIRE-CONSISTENCY, in effect, says that valid programs do<P>
|
|
not cause any of these situations to occur, and the behavior in such<P>
|
|
cases is unspecified (allowing both models to be used as valid<P>
|
|
implementation techniques).<P>
|
|
<P>
|
|
(1) The situation where the file does not contain a <A REL=DEFINITION HREF="../Body/m_in_pkg.htm#in-package"><B>IN-PACKAGE</B></A><P>
|
|
and where the compile-time value of <A REL=DEFINITION HREF="../Body/v_pkg.htm#STpackageST"><B>*PACKAGE*</B></A> is a package with a<P>
|
|
different name than the load-time value of <A REL=DEFINITION HREF="../Body/v_pkg.htm#STpackageST"><B>*PACKAGE*</B></A>.<P>
|
|
<P>
|
|
The current-package model would <A REL=DEFINITION HREF="../Body/f_intern.htm#intern"><B>intern</B></A> the names of symbols that <P>
|
|
were accessible in <A REL=DEFINITION HREF="../Body/v_pkg.htm#STpackageST"><B>*PACKAGE*</B></A> at compile time in <A REL=DEFINITION HREF="../Body/v_pkg.htm#STpackageST"><B>*PACKAGE*</B></A> at load time.<P>
|
|
<P>
|
|
The home-package model would <A REL=DEFINITION HREF="../Body/f_intern.htm#intern"><B>intern</B></A> the names of symbols that<P>
|
|
were accessible in <A REL=DEFINITION HREF="../Body/v_pkg.htm#STpackageST"><B>*PACKAGE*</B></A> at compile time in the package with<P>
|
|
the same name as their compile-time home package.<P>
|
|
<P>
|
|
In general, programs must be compiled in the "right" package, so<P>
|
|
that the compiler can find and apply the correct macro expansions,<P>
|
|
type definitions, and so on; see issue COMPILE-ENVIRONMENT-CONSISTENCY.<P>
|
|
As a result of macroexpansion or other transformations applied by<P>
|
|
the compiler, the compiled file may contain symbol references that<P>
|
|
were not present in the source file. The current-package model may<P>
|
|
cause problems because these references may be resolved to be<P>
|
|
symbols other than the ones that were intended. The home-package<P>
|
|
model is more likely to find the correct symbols at load time.<P>
|
|
<P>
|
|
(2) The situation where there is a symbol accessible in the<P>
|
|
compile-time value of <A REL=DEFINITION HREF="../Body/v_pkg.htm#STpackageST"><B>*PACKAGE*</B></A> but with another home package, and<P>
|
|
where at load time there is not a symbol with the same name that<P>
|
|
is accessible in both packages. This situation might occur, for<P>
|
|
example, if at compile time there is a symbol that is external in<P>
|
|
its home package and that package is used by <A REL=DEFINITION HREF="../Body/v_pkg.htm#STpackageST"><B>*PACKAGE*</B></A>, but where<P>
|
|
there is no such external symbol in that package at load time, or<P>
|
|
the load-time <A REL=DEFINITION HREF="../Body/v_pkg.htm#STpackageST"><B>*PACKAGE*</B></A> does not use the other package.<P>
|
|
<P>
|
|
The current-package model would find or create a symbol accessible<P>
|
|
in <A REL=DEFINITION HREF="../Body/v_pkg.htm#STpackageST"><B>*PACKAGE*</B></A>.<P>
|
|
<P>
|
|
The home-package model would find or create a symbol accessible in<P>
|
|
a package with the same name as the symbol's compile-time home<P>
|
|
package.<P>
|
|
<P>
|
|
Some people feel that the behavior of the current-package model is<P>
|
|
more intuitive in this situation, and that it is more forgiving of<P>
|
|
differences between the compile-time and load-time package<P>
|
|
structures. Others feel that the behavior of the home-package<P>
|
|
model is more intuitive, and that if there have been significant<P>
|
|
changes to the package structures, it is probably an indication<P>
|
|
that the file needs to be recompiled anyway, since the compiler<P>
|
|
might have picked up macro definitions and the like from the<P>
|
|
wrong package. <P>
|
|
<P>
|
|
(3) The situation where a symbol is external in its home package<P>
|
|
and where there is no such external symbol in that package at load<P>
|
|
time.<P>
|
|
<P>
|
|
The current-package model would quietly find or create the symbol<P>
|
|
in <A REL=DEFINITION HREF="../Body/v_pkg.htm#STpackageST"><B>*PACKAGE*</B></A> if the symbol were accessible in <A REL=DEFINITION HREF="../Body/v_pkg.htm#STpackageST"><B>*PACKAGE*</B></A> at compile<P>
|
|
time. Otherwise, it will signal an error.<P>
|
|
<P>
|
|
The home-package model would always just quietly find or create the <P>
|
|
symbol as internal in its home package.<P>
|
|
<P>
|
|
Not complaining when a symbol that is supposed to be external<P>
|
|
isn't can be seen as a violation of modularity. However, it seems<P>
|
|
like this argument should apply equally to symbols whose home<P>
|
|
package is <A REL=DEFINITION HREF="../Body/v_pkg.htm#STpackageST"><B>*PACKAGE*</B></A> as symbols whose home package is somewhere<P>
|
|
else.<P>
|
|
<P>
|
|
<P>
|
|
<B>Discussion:<P>
|
|
</B><P>
|
|
There has been some further and lengthy discussion on the question of<P>
|
|
whether this proposal overspecifies the behavior of <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A> and<P>
|
|
<A REL=DEFINITION HREF="../Body/f_load.htm#load"><B>LOAD</B></A>. At least one person would like the <A REL=DEFINITION HREF="../Body/07_ffb.htm#standard"><B>standard</B></A> to say nothing on<P>
|
|
this issue beyond a statement of the goal that loading a compiled file<P>
|
|
should exhibit the same behavior as loading its source file. We have<P>
|
|
also considered another approach to the problem that would place more<P>
|
|
stringent requirements on conforming programs and fewer requirements<P>
|
|
on implementations. Neither of these alternatives seems to have much<P>
|
|
support, though.<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>
|