154 lines
8.9 KiB
HTML
154 lines
8.9 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 CONDITION-SLOTS 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/iss075_w.htm">
|
||
|
|
<LINK REL=UP HREF="../Issues/iss077.htm">
|
||
|
|
<LINK REL=NEXT HREF="../Issues/iss078_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/iss075_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Previous]" SRC="../Graphics/Prev.gif" ALIGN=Bottom></A><A REL=UP HREF="../Issues/iss077.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Up]" SRC="../Graphics/Up.gif" ALIGN=Bottom></A><A REL=NEXT HREF="../Issues/iss078_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Next]" SRC="../Graphics/Next.gif" ALIGN=Bottom></A></H1>
|
||
|
|
|
||
|
|
<HR>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<H2>Issue CONDITION-SLOTS Writeup</H2>
|
||
|
|
|
||
|
|
<PRE><B>Issue:</B> <A HREF="iss077.htm">CONDITION-SLOTS</A><P>
|
||
|
|
<P>
|
||
|
|
<B>References:</B> Condition System, version 18<P>
|
||
|
|
Issue <A HREF="iss049.htm">CLOS-CONDITIONS</A><P>
|
||
|
|
Issue <A HREF="iss252.htm">PACKAGE-CLUTTER</A><P>
|
||
|
|
ANSI CL draft pp.5-4, 5-5<P>
|
||
|
|
<P>
|
||
|
|
<B>Category:</B> CLARIFICATION<P>
|
||
|
|
<P>
|
||
|
|
<B>Edit history:</B> 3-Jan-90, Version 1 by Barrett<P>
|
||
|
|
30-Apr-90, Version 2 by Moon (rewrite, just one proposal,<P>
|
||
|
|
extend to cover all specified objects that have slots)<P>
|
||
|
|
<P>
|
||
|
|
<B>Problem description:<P>
|
||
|
|
</B><P>
|
||
|
|
Pages 5-4 and 5-5 of the ANSI CL draft specification from last fall refer<P>
|
||
|
|
to slots of specified conditions. However these slots were not put into<P>
|
||
|
|
the specification in a consistent way.<P>
|
||
|
|
<P>
|
||
|
|
<A HREF="iss049.htm">CLOS-CONDITIONS:INTEGRATE</A>, which was adopted by X3J13, changed condition<P>
|
||
|
|
slots to be the same as CLOS slots, but did not say that the specified<P>
|
||
|
|
conditions have any specified slots. However, some people have taken it<P>
|
||
|
|
to mean that the condition classes defined by the <A REL=DEFINITION HREF="../Body/07_ffb.htm#standard"><B>standard</B></A> all contain<P>
|
||
|
|
slots whose names are external symbols in the CL package which are<P>
|
||
|
|
<A REL=DEFINITION HREF="../Body/f_stgeq_.htm#stringEQ"><B>STRING=</B></A> to the specified initargs for creating conditions. The ANSI CL<P>
|
||
|
|
draft specification was edited in some places as if this were true.<P>
|
||
|
|
<P>
|
||
|
|
Revision 18 of the conditions document, which was adopted by X3J13,<P>
|
||
|
|
refers to initialization arguments and accessors, but carefully avoids<P>
|
||
|
|
naming the slots themselves. The philosophy of that document was that<P>
|
||
|
|
slots are only defined for programmer defined conditions, and that the<P>
|
||
|
|
only sanctioned interface for the <A REL=DEFINITION HREF="../Body/07_ffb.htm#standard"><B>standard</B></A> condition classes is through<P>
|
||
|
|
the use of the defined accessor functions.<P>
|
||
|
|
<P>
|
||
|
|
A related, more general issue that <A HREF="iss252.htm">PACKAGE-CLUTTER:REDUCE</A> failed to<P>
|
||
|
|
address is whether there are naming restrictions on<P>
|
||
|
|
implementation-dependent slots of specified classes.<P>
|
||
|
|
<P>
|
||
|
|
This is Symbolics issue #8 and Loosemore issue #15 of 27 Feb 90.<P>
|
||
|
|
<P>
|
||
|
|
<B>Proposal (CONDITION-SLOTS:HIDDEN):<P>
|
||
|
|
</B><P>
|
||
|
|
1. Clarify that no specified condition classes have any specified slots.<P>
|
||
|
|
The implementation of the required information storage by the specified<P>
|
||
|
|
condition classes is implementation-dependent. We need to be clear that<P>
|
||
|
|
specified conditions are not required to have any particular slots with<P>
|
||
|
|
any particular names. They -are- required to be the type of object that<P>
|
||
|
|
is able to have slots. User-defined conditions -are- required to have<P>
|
||
|
|
slots with the names mentioned in the <A REL=DEFINITION HREF="../Body/m_defi_5.htm#define-condition"><B>DEFINE-CONDITION</B></A> form.<P>
|
||
|
|
<P>
|
||
|
|
2. Table 5-1 in the ANSI CL draft specification should not contain slot<P>
|
||
|
|
names, because they will not necessarily be accessible via <A REL=DEFINITION HREF="../Body/m_w_slts.htm#with-slots"><B>WITH-SLOTS</B></A> in<P>
|
||
|
|
the way people might infer. Instead, the table should mention initargs<P>
|
||
|
|
and accessors. For example, :FORMAT-STRING and<P>
|
||
|
|
SIMPLE-CONDITION-FORMAT-STRING -- but not the symbol FORMAT-STRING.<P>
|
||
|
|
<P>
|
||
|
|
3. Define that it is unspecified whether slots are involved in the<P>
|
||
|
|
operation of specified functions on instances of specified classes,<P>
|
||
|
|
except when slots are explicitly specified by the <A REL=DEFINITION HREF="../Body/07_ffb.htm#standard"><B>standard</B></A>.<P>
|
||
|
|
<P>
|
||
|
|
4. Define that if in a particular implementation a specified <A REL=DEFINITION HREF="../Body/t_class.htm#class"><B>class</B></A> has<P>
|
||
|
|
slots that are not specified by the <A REL=DEFINITION HREF="../Body/07_ffb.htm#standard"><B>standard</B></A>, the names of these slots<P>
|
||
|
|
must not be external symbols of packages defined in the <A REL=DEFINITION HREF="../Body/07_ffb.htm#standard"><B>standard</B></A> nor<P>
|
||
|
|
otherwise accessible in the USER package.<P>
|
||
|
|
<P>
|
||
|
|
<B>Rationale:<P>
|
||
|
|
</B><P>
|
||
|
|
Allowing the information storage to be implementation-dependent is<P>
|
||
|
|
essential to compatibility with existing systems, which may not represent<P>
|
||
|
|
this information in the "obvious" way.<P>
|
||
|
|
<P>
|
||
|
|
Specifying slots for the condition classes would <A REL=DEFINITION HREF="../Body/f_provid.htm#require"><B>require</B></A> putting the slot<P>
|
||
|
|
names into the COMMON-LISP package, adding many symbols.<P>
|
||
|
|
<P>
|
||
|
|
Part 4 of the proposal repairs an omission in <A HREF="iss252.htm">PACKAGE-CLUTTER:REDUCE</A>. It<P>
|
||
|
|
is necessary if users are to be able to define a subclass of a condition<P>
|
||
|
|
<A REL=DEFINITION HREF="../Body/t_class.htm#class"><B>class</B></A> (which is necessary whenever users define their own conditions) and<P>
|
||
|
|
give slots to their <A REL=DEFINITION HREF="../Body/t_class.htm#class"><B>class</B></A> without potentially interfering with<P>
|
||
|
|
implementation-defined slots.<P>
|
||
|
|
<P>
|
||
|
|
<B>Current practice:<P>
|
||
|
|
</B><P>
|
||
|
|
Parts 1 through 3 are likely to be consistent with all existing<P>
|
||
|
|
implementations. Part 4 is not known to be specifically violated by any<P>
|
||
|
|
implementation, but it might well be violated by accident. I have not<P>
|
||
|
|
tested any implementations specifically.<P>
|
||
|
|
<P>
|
||
|
|
<B>Cost to Implementors:<P>
|
||
|
|
</B><P>
|
||
|
|
Easy, all they have to do is keep slot names out of user visible packages.<P>
|
||
|
|
<P>
|
||
|
|
<B>Cost to Users:<P>
|
||
|
|
</B><P>
|
||
|
|
Easy, all they have to do is use the specified accessors rather than<P>
|
||
|
|
<A REL=DEFINITION HREF="../Body/f_slt_va.htm#slot-value"><B>SLOT-VALUE</B></A> or <A REL=DEFINITION HREF="../Body/m_w_slts.htm#with-slots"><B>WITH-SLOTS</B></A> to access information in conditions.<P>
|
||
|
|
<P>
|
||
|
|
<B>Cost of non-adoption:<P>
|
||
|
|
</B><P>
|
||
|
|
Substantially increased size of the COMMON-LISP package and considerable<P>
|
||
|
|
extra work on the ANSI CL specification to document all the slots.<P>
|
||
|
|
Porting problems for any code that defines its own condition types<P>
|
||
|
|
because of slot name collisions.<P>
|
||
|
|
<P>
|
||
|
|
<B>Performance impact:<P>
|
||
|
|
</B><P>
|
||
|
|
None of any consequence. <A REL=DEFINITION HREF="../Body/f_slt_va.htm#slot-value"><B>SLOT-VALUE</B></A> might be faster than calling an<P>
|
||
|
|
accessor in some implementations (although in most implementations it is<P>
|
||
|
|
slower, when not called from a <A REL=DEFINITION HREF="../Body/t_method.htm#method"><B>method</B></A>), but access to a slot of a<P>
|
||
|
|
condition never occurs in important inner loops.<P>
|
||
|
|
<P>
|
||
|
|
<B>Benefits:<P>
|
||
|
|
</B><P>
|
||
|
|
Conditions will be specified as originally intended.<P>
|
||
|
|
<P>
|
||
|
|
<B>Esthetics:<P>
|
||
|
|
</B><P>
|
||
|
|
Abstraction is better than mandating one particular implementation<P>
|
||
|
|
of information storage.<P>
|
||
|
|
<P>
|
||
|
|
<B>Discussion:<P>
|
||
|
|
</B><P>
|
||
|
|
None.<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>
|