0.8.1.11:

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

diff --git a/doc/beyond-ansi.sgml b/doc/beyond-ansi.sgml
index 1990336..694898a 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>
 
@@ -323,11 +336,9 @@ fixed addresses, a precondition for using copy-on-write to share code
 between multiple Lisp processes. is less important with modern
 generational garbage collectors. </para>
 
-<para>The <function>sb-ext:truly-the</> operator does what the
-<function>cl:the</> operator does in a more conventional
-implementation of &CommonLisp;, declaring the type of its argument
-without any runtime checks. (Ordinarily in &SBCL;, any type
-declaration is treated as an assertion and checked at runtime.)</para>
+<para>The <function>sb-ext:truly-the</> declares the type of the
+result of the operations, producing its argument; the declaration is
+not checked. In short: don't use it.</para>
 
 <para>The <function>sb-ext:freeze-type</> declaration declares that a
 type will never change, which can make type testing
@@ -340,9 +351,11 @@ to it. This is appropriate for functions like <function>sqrt</>, but
 is <emphasis>not</> appropriate for functions like <function>aref</>,
 which can change their return values when the underlying data are
 changed.</para>
+<!-- FIXME: This declaration does not seem to be supported in the --
+  -- current compiler. -->
 
 </sect2>
 
 </sect1>
 
-</chapter>
\ No newline at end of file
+</chapter>