157 lines
9.2 KiB
HTML
157 lines
9.2 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 CLOS-CONDITIONS-AGAIN 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/iss047_w.htm">
|
|
<LINK REL=UP HREF="../Issues/iss048.htm">
|
|
<LINK REL=NEXT HREF="../Issues/iss049_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/iss047_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Previous]" SRC="../Graphics/Prev.gif" ALIGN=Bottom></A><A REL=UP HREF="../Issues/iss048.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Up]" SRC="../Graphics/Up.gif" ALIGN=Bottom></A><A REL=NEXT HREF="../Issues/iss049_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Next]" SRC="../Graphics/Next.gif" ALIGN=Bottom></A></H1>
|
|
|
|
<HR>
|
|
|
|
|
|
|
|
<H2>Issue CLOS-CONDITIONS-AGAIN Writeup</H2>
|
|
|
|
<PRE>Date: Fri, 8 Jun 90 19:55 EDT<P>
|
|
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM><P>
|
|
Subject: Issue: <A HREF="iss048.htm">CLOS-CONDITIONS-AGAIN</A> (Version 6)<P>
|
|
To: X3J13@mcc.com<P>
|
|
Message-ID: <19900608235525.3.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM><P>
|
|
<P>
|
|
This version includes the amendment that was passed at the X3J13 meeting today.<P>
|
|
<P>
|
|
<B>Issue:</B> <A HREF="iss048.htm">CLOS-CONDITIONS-AGAIN</A><P>
|
|
<P>
|
|
<B>References:</B> ANSI CL draft specification, page 5-4<P>
|
|
<P>
|
|
Related issues: <A HREF="iss049.htm">CLOS-CONDITIONS</A><P>
|
|
<P>
|
|
<B>Category:</B> ADDITION and CHANGE<P>
|
|
<P>
|
|
<B>Edit history:</B> 30-Apr-90, Version 1 by Moon (for Pitman)<P>
|
|
30-Apr-90, Version 2 by Moon (deal with slots)<P>
|
|
2-May-90, Version 3 by Pitman (minor wording clarifications)<P>
|
|
2-May-90, Version 4 by Moon (final check for typos)<P>
|
|
5-Jun-90, Version 5 by Moon (mention multiple inheritance)<P>
|
|
8-Jun-90, Version 6, by Moon (as amended at X3J13 meeting)<P>
|
|
<P>
|
|
<B>Problem description:<P>
|
|
</B><P>
|
|
The condition system should not be too tightly integrated into CLOS, for<P>
|
|
two reasons: Some implementations already have a native condition system<P>
|
|
that is not based on CLOS, and it should be possible to integrate the<P>
|
|
native conditions and the ANSI CL conditions. Some people would like to<P>
|
|
define an ANSI Common Lisp subset that does not contain CLOS but does<P>
|
|
contain conditions.<P>
|
|
<P>
|
|
The problem areas are the use of <A REL=DEFINITION HREF="../Body/m_defcla.htm#defclass"><B>DEFCLASS</B></A>, <A REL=DEFINITION HREF="../Body/f_mk_ins.htm#make-instance"><B>MAKE-INSTANCE</B></A>, and <A REL=DEFINITION HREF="../Body/m_defmet.htm#defmethod"><B>DEFMETHOD</B></A><P>
|
|
to define and create conditions, rather than using more abstract macros<P>
|
|
that conceal the implementation of conditions in terms of CLOS, and<P>
|
|
exposure of the implementation of condition slots as CLOS slots. If user<P>
|
|
code was written in a more abstract way, it could run in a subset language<P>
|
|
that did not contain CLOS.<P>
|
|
<P>
|
|
This is Symbolics issue #7.<P>
|
|
<P>
|
|
<B>Proposal (CLOS-CONDITIONS-AGAIN:ALLOW-SUBSET):<P>
|
|
</B> <P>
|
|
1. Specify that conforming code must use <A REL=DEFINITION HREF="../Body/m_defi_5.htm#define-condition"><B>DEFINE-CONDITION</B></A> (not <A REL=DEFINITION HREF="../Body/m_defcla.htm#defclass"><B>DEFCLASS</B></A>)<P>
|
|
to define conditions, and <A REL=DEFINITION HREF="../Body/f_mk_cnd.htm#make-condition"><B>MAKE-CONDITION</B></A> (not <A REL=DEFINITION HREF="../Body/f_mk_ins.htm#make-instance"><B>MAKE-INSTANCE</B></A>) to make<P>
|
|
conditions. (These two operators already exist in ANSI Common Lisp.)<P>
|
|
<P>
|
|
2. Specify that conforming code must use the :REPORT option of<P>
|
|
<A REL=DEFINITION HREF="../Body/m_defi_5.htm#define-condition"><B>DEFINE-CONDITION</B></A> (not <A REL=DEFINITION HREF="../Body/m_defmet.htm#defmethod"><B>DEFMETHOD</B></A> for <A REL=DEFINITION HREF="../Body/f_pr_obj.htm#print-object"><B>PRINT-OBJECT</B></A>) to define a condition<P>
|
|
reporter.<P>
|
|
<P>
|
|
3. Specify that conforming code must not use <A REL=DEFINITION HREF="../Body/f_slt_va.htm#slot-value"><B>SLOT-VALUE</B></A>, <A REL=DEFINITION HREF="../Body/f_slt_bo.htm#slot-boundp"><B>SLOT-BOUNDP</B></A>,<P>
|
|
<A REL=DEFINITION HREF="../Body/f_slt_ma.htm#slot-makunbound"><B>SLOT-MAKUNBOUND</B></A>, or <A REL=DEFINITION HREF="../Body/m_w_slts.htm#with-slots"><B>WITH-SLOTS</B></A> on condition objects. Instead it must<P>
|
|
call the accessor functions defined by <A REL=DEFINITION HREF="../Body/m_defi_5.htm#define-condition"><B>DEFINE-CONDITION</B></A>.<P>
|
|
<P>
|
|
4. Clarify that this proposal does not rule out the use of multiple<P>
|
|
parent-types in <A REL=DEFINITION HREF="../Body/m_defi_5.htm#define-condition"><B>DEFINE-CONDITION</B></A>.<P>
|
|
<P>
|
|
<B>Rationale:<P>
|
|
</B><P>
|
|
1. The reasons are two:<P>
|
|
- permit flexibility in making the native <A REL=DEFINITION HREF="../Body/t_class.htm#class"><B>class</B></A> system compatible<P>
|
|
with the ANSI CL one<P>
|
|
- permit dialects that don't want CLOS to be available to run most<P>
|
|
common condition-related code.<P>
|
|
<P>
|
|
2. The reasons are three:<P>
|
|
- isolate the report part without forcing the user to deal with the<P>
|
|
case of <A REL=DEFINITION HREF="../Body/v_pr_esc.htm#STprint-escapeST"><B>*PRINT-ESCAPE*</B></A> being true.<P>
|
|
- keep a CL subset from having to implement <A REL=DEFINITION HREF="../Body/m_defmet.htm#defmethod"><B>DEFMETHOD</B></A> to get this<P>
|
|
important functionality.<P>
|
|
- don't define two ways to do the same thing.<P>
|
|
<P>
|
|
3. Using the existing accessor functions seems more conservative than<P>
|
|
requiring non-CLOS subsets to implement an ersatz <A REL=DEFINITION HREF="../Body/f_slt_va.htm#slot-value"><B>SLOT-VALUE</B></A> function.<P>
|
|
<P>
|
|
Note also that the requirement here (in #3) is on conforming -code-.<P>
|
|
An -implementation- can permit the use of <A REL=DEFINITION HREF="../Body/f_slt_va.htm#slot-value"><B>SLOT-VALUE</B></A>, <A REL=DEFINITION HREF="../Body/f_slt_bo.htm#slot-boundp"><B>SLOT-BOUNDP</B></A>,<P>
|
|
<A REL=DEFINITION HREF="../Body/f_slt_ma.htm#slot-makunbound"><B>SLOT-MAKUNBOUND</B></A>, and/or <A REL=DEFINITION HREF="../Body/m_w_slts.htm#with-slots"><B>WITH-SLOTS</B></A> as an extension and still be <P>
|
|
conforming. Programs which used such an extension would not be<P>
|
|
conforming and might not be portable to all implementations.<P>
|
|
<P>
|
|
4. There is no substitute for multiple inheritance, and given the<P>
|
|
limited set of operations that can be performed on conditions, it<P>
|
|
is easy to fake it.<P>
|
|
<P>
|
|
<B>Current practice:<P>
|
|
</B><P>
|
|
1. <A REL=DEFINITION HREF="../Body/m_defi_5.htm#define-condition"><B>DEFINE-CONDITION</B></A> and <A REL=DEFINITION HREF="../Body/f_mk_cnd.htm#make-condition"><B>MAKE-CONDITION</B></A> are already in the language.<P>
|
|
<P>
|
|
2. The :REPORT option to <A REL=DEFINITION HREF="../Body/m_defi_5.htm#define-condition"><B>DEFINE-CONDITION</B></A> exists.<P>
|
|
<P>
|
|
3. Some implementations support use of <A REL=DEFINITION HREF="../Body/m_w_slts.htm#with-slots"><B>WITH-SLOTS</B></A> and some do not.<P>
|
|
Programs that use <A REL=DEFINITION HREF="../Body/m_w_slts.htm#with-slots"><B>WITH-SLOTS</B></A> are not yet portable.<P>
|
|
<P>
|
|
4. <A REL=DEFINITION HREF="../Body/m_defi_5.htm#define-condition"><B>DEFINE-CONDITION</B></A> is already specified to support multiple inheritance.<P>
|
|
<P>
|
|
<B>Cost to Implementors:<P>
|
|
</B><P>
|
|
Trivial.<P>
|
|
<P>
|
|
<B>Cost to Users:<P>
|
|
</B><P>
|
|
They have to write their programs in terms of the condition abstractions<P>
|
|
if they want them to be portable.<P>
|
|
<P>
|
|
<B>Cost of non-adoption:<P>
|
|
</B><P>
|
|
Condition-using programs will not be portable to Common Lisp subsets that<P>
|
|
don't have CLOS.<P>
|
|
<P>
|
|
<B>Performance impact:<P>
|
|
</B><P>
|
|
None.<P>
|
|
<P>
|
|
<B>Benefits:<P>
|
|
</B><P>
|
|
See rationale.<P>
|
|
<P>
|
|
<B>Esthetics:<P>
|
|
</B><P>
|
|
Abstraction is more esthetic than revealing the implementation.<P>
|
|
<P>
|
|
<B>Discussion:<P>
|
|
</B><P>
|
|
Pitman and Moon support this proposal.<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>
|