167 lines
8.7 KiB
HTML
167 lines
8.7 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 BOA-AUX-INITIALIZATION 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/iss017_w.htm">
|
|
<LINK REL=UP HREF="../Issues/iss019.htm">
|
|
<LINK REL=NEXT HREF="../Issues/iss020_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/iss017_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Previous]" SRC="../Graphics/Prev.gif" ALIGN=Bottom></A><A REL=UP HREF="../Issues/iss019.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Up]" SRC="../Graphics/Up.gif" ALIGN=Bottom></A><A REL=NEXT HREF="../Issues/iss020_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Next]" SRC="../Graphics/Next.gif" ALIGN=Bottom></A></H1>
|
|
|
|
<HR>
|
|
|
|
|
|
|
|
<H2>Issue BOA-AUX-INITIALIZATION Writeup</H2>
|
|
|
|
<PRE><B>Forum:</B> Public Review<P>
|
|
<B>Issue:</B> <A HREF="iss019.htm">BOA-AUX-INITIALIZATION</A><P>
|
|
<B>References:</B> Loosemore's public review comment #26<P>
|
|
Boa <A REL=DEFINITION HREF="../Body/a_lambda.htm#lambda"><B>lambda</B></A> lists, Section 3.4.6, page 3-48<P>
|
|
<A REL=DEFINITION HREF="../Body/m_defstr.htm#defstruct"><B>DEFSTRUCT</B></A> :TYPE slot option, page 8-4<P>
|
|
<A REL=DEFINITION HREF="../Body/m_defstr.htm#defstruct"><B>DEFSTRUCT</B></A> slot-initform, page 8-3<P>
|
|
CLtL-2 p 482<P>
|
|
Issue <A HREF="iss355.htm">UNINITIALIZED-ELEMENTS</A><P>
|
|
<B>Category:</B> CLARIFICATION/CHANGE<P>
|
|
<B>Edit history:</B> 26 Dec 1992, Version 1 by Loosemore<P>
|
|
<B>Status:</B> Proposal ERROR-ON-READ failed 7-3 on letter ballot 93-302.<P>
|
|
Proposal ERROR-ON-READ passed 7-0 at October 1993 meeting.<P>
|
|
<P>
|
|
<P>
|
|
<B>Problem description:<P>
|
|
</B><P>
|
|
In the discussion of BOA constructor <A REL=DEFINITION HREF="../Body/a_lambda.htm#lambda"><B>lambda</B></A> lists on page 3-48<P>
|
|
says that, for a slot whose name is given as an <A REL=DEFINITION HREF="../Body/03_da.htm#AMaux"><B>&AUX</B></A> variable<P>
|
|
without an initialization form, the "slot is not initialized; its<P>
|
|
initial value is implementation-defined." The corresponding<P>
|
|
passage from CLtL says the initial value is "undefined" rather<P>
|
|
than "implementation-defined".<P>
|
|
<P>
|
|
It is not clear whether and when errors about the uninitialized slot<P>
|
|
might be detected. If the slot is given an "implementation-defined"<P>
|
|
value, for example, is it permissible for the implementation to<P>
|
|
signal an error at instance creation time if the slot :TYPE for<P>
|
|
the uninitialized slot doesn't match the type of the value that<P>
|
|
particular implementation has chosen? Or is it permissible for<P>
|
|
implementations to signal an error if an attempt is later made to<P>
|
|
read the slot's value before it has been explicitly assigned a <P>
|
|
(type-correct) value?<P>
|
|
<P>
|
|
<P>
|
|
<B>Proposal (BOA-AUX-INITIALIZATION:ERROR-ON-READ):<P>
|
|
</B><P>
|
|
Make BOA constructors with <A REL=DEFINITION HREF="../Body/03_da.htm#AMaux"><B>&AUX</B></A> variables without an initialization<P>
|
|
form treat the corresponding slots in the same way as slots defined <P>
|
|
without an slot-initform; the consequences are undefined if an attempt<P>
|
|
is later made to read the slot's value before a value is explicitly <P>
|
|
assigned.<P>
|
|
<P>
|
|
Clarify that, if such a slot has a :TYPE option specified, there can<P>
|
|
be no type mismatch error when initialization of the slot is suppressed<P>
|
|
in this way.<P>
|
|
<P>
|
|
<P>
|
|
<B>Rationale:<P>
|
|
</B><P>
|
|
This makes the treatment of uninitialized <A REL=DEFINITION HREF="../Body/f_docume.htm#structure"><B>structure</B></A> slots consistent.<P>
|
|
It also makes it permissible for implementations to diagnose references<P>
|
|
to uninitialized <A REL=DEFINITION HREF="../Body/f_docume.htm#structure"><B>structure</B></A> slots in high-safety code, which is helpful<P>
|
|
in debugging. (See issue <A HREF="iss355.htm">UNINITIALIZED-ELEMENTS</A>.)<P>
|
|
<P>
|
|
The interpretation of the <A REL=DEFINITION HREF="../Body/03_da.htm#AMaux"><B>&AUX</B></A> syntax in BOA constructors was carefully<P>
|
|
chosen to permit the default <A REL=DEFINITION HREF="../Body/f_docume.htm#structure"><B>structure</B></A> slot initializations to be<P>
|
|
overridden completely. There are some circumstances -- such as when<P>
|
|
setting up complicated circular data structures -- when there is<P>
|
|
simply no appropriate value that could be used as a default. While<P>
|
|
one could simply specify the <A REL=DEFINITION HREF="../Body/m_defstr.htm#defstruct"><B>DEFSTRUCT</B></A> definition without slot-initforms<P>
|
|
for those slots to get the right behavior, one would also lose the <P>
|
|
benefit of type-checking on accesses to the slot since <A REL=DEFINITION HREF="../Body/m_defstr.htm#defstruct"><B>DEFSTRUCT</B></A><P>
|
|
syntax allows one to specify the :TYPE option only if a slot-initform<P>
|
|
is also specified.<P>
|
|
<P>
|
|
<P>
|
|
<B>Current practice:<P>
|
|
</B><P>
|
|
At least one implementation (CMU CL) signals a type mismatch error at<P>
|
|
instance creation time if the slot type you specified doesn't match<P>
|
|
that of the value that particular implementation has chosen to store<P>
|
|
in these slots.<P>
|
|
<P>
|
|
Other implementations either do no type checking, or defer type <P>
|
|
checking until when the slot's value is read.<P>
|
|
<P>
|
|
<P>
|
|
<B>Cost to implementors:<P>
|
|
</B><P>
|
|
Those implementations that now do type-checking at instance creation<P>
|
|
time will have to be changed. This is probably not a huge change.<P>
|
|
<P>
|
|
<P>
|
|
<B>Cost to users:<P>
|
|
</B><P>
|
|
Some user code may be broken by this change; but such code is already<P>
|
|
nonportable.<P>
|
|
<P>
|
|
<P>
|
|
<B>Aesthetics:<P>
|
|
</B><P>
|
|
Making the language more consistent is a good idea.<P>
|
|
<P>
|
|
<P>
|
|
<B>Editorial impact:<P>
|
|
</B><P>
|
|
Tweaking two sentences on page 3-48.<P>
|
|
<P>
|
|
<P>
|
|
<B>Discussion:<P>
|
|
</B><P>
|
|
The consensus of the public review committee was that this proposal<P>
|
|
was the best of the alternatives.<P>
|
|
<P>
|
|
Clarifying that we really want the initial value of these slots to be<P>
|
|
"implementation-defined" would have the problem that it would be<P>
|
|
impossible for users to portably specify a slot :TYPE other than T.<P>
|
|
<P>
|
|
The possibility of having the <A REL=DEFINITION HREF="../Body/07_ffb.htm#standard"><B>standard</B></A> specify an explicit value (<A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A>) <P>
|
|
for uninitialized slots was also mentioned, but this was considered <P>
|
|
unaesthetic; it would still weaken type-checking to some extent, make <P>
|
|
it harder to detect uninitialized slots, and be inconsistent with other<P>
|
|
parts of the language.<P>
|
|
<P>
|
|
Rob MacLachlan says, about CMU CL's behavior:<P>
|
|
<P>
|
|
Our interpretation is that the slot type declaration must encompass<P>
|
|
all values that the slot can be created with. This is important,<P>
|
|
since we want all possible values of the slot accessor to be of that<P>
|
|
type.<P>
|
|
<P>
|
|
(In other words, it appears they want to <A REL=DEFINITION HREF="../Body/m_do_do.htm#do"><B>do</B></A> type-checking <A REL=DEFINITION HREF="../Body/m_when_.htm#when"><B>when</B></A> <A REL=DEFINITION HREF="../Body/s_the.htm#the"><B>the</B></A><P>
|
|
slots are written rather than <A REL=DEFINITION HREF="../Body/m_when_.htm#when"><B>when</B></A> they are <A REL=DEFINITION HREF="../Body/f_rd_rd.htm#read"><B>read</B></A>, since writing is<P>
|
|
a less frequent operation.) <P>
|
|
<P>
|
|
<P>
|
|
<P>
|
|
<P>
|
|
<P>
|
|
<P>
|
|
<P>
|
|
<P>
|
|
<P>
|
|
<P>
|
|
<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>
|