0.8.0.78.vector-nil-string.11:

[sbcl.git] / doc / beyond-ansi.sgml

diff --git a/doc/beyond-ansi.sgml b/doc/beyond-ansi.sgml
index 1990336..1558f3c 100644 (file)
--- a/doc/beyond-ansi.sgml
+++ b/doc/beyond-ansi.sgml
@@ -48,7 +48,7 @@ of the same symbol more than once is undefined unless the new value
 is <function>eql</> to the old value. Conforming to this specification
 is a nuisance when the "constant" value is only constant under some
 weaker test like <function>string=</> or <function>equal</>. It's
-especially annoying because <function>defconstant</> takes effect
+especially annoying because, in &SBCL;, <function>defconstant</> takes effect
 not only at load time but also at compile time, so that just 
 compiling and loading reasonable code like 
 <programlisting>(defconstant +foobyte+ '(1 4))</>
@@ -63,7 +63,11 @@ E.g., the code above can be given an exactly defined meaning by replacing
 <function>defconstant</> either with <function>defparameter</> or 
 with a customized macro which does the right thing, possibly along the
 lines of the <function>defconstant-eqx</> macro used internally in the
-implementation of SBCL itself.</para>
+implementation of &SBCL; itself.  In circumstances where this is not 
+appropriate, the programmer can handle the condition type 
+<errortype>sb-ext:defconstant-uneql</errortype>, and choose either the 
+<action>continue</action> or <action>abort</action> restart as 
+appropriate.</para>
 
 <para>&SBCL; gives style warnings about various kinds of perfectly
 legal code, e.g.
@@ -118,12 +122,21 @@ whose instances can be used as Lisp streams (e.g. passed as the
 first argument to <function>format</>).</para>
 
 <para>&SBCL; supports a MetaObject Protocol which is intended to be
-compatible with &AMOP;; exceptions to this (as distinct from current
-bugs<!-- Such as the distinction between CL:FIND-CLASS and
-SB-PCL::FIND-CLASS :-( -->) are that
-<function>compute-effective-method</> only returns one value, not
-two<!-- FIXME: anything else? What about extensions? (e.g. COMPUTE-SLOTS
-behaviour) -->.</para>
+compatible with &AMOP;; present exceptions to this (as distinct from
+current bugs) are:
+<itemizedlist>
+  <listitem><para>the abstract <classname>metaobject</> class is not
+    present in the class hierarchy;</para></listitem>
+  <listitem><para>the <classname>standard-object</> and
+    <classname>funcallable-standard-object</> classes are
+    disjoint;</para></listitem>
+  <listitem><para><function>compute-effective-method</> only returns
+    one value, not two;</para></listitem>
+  <listitem><para>the system-supplied <property>:around</> method for
+    <function>compute-slots</> specialized on
+    <classname>funcallable-standard-class</> does not respect the
+    requested order from a user-supplied primary method.
+</itemizedlist>
 
 </sect2>