0.9.8.38:

[sbcl.git] / doc / manual / beyond-ansi.texinfo

diff --git a/doc/manual/beyond-ansi.texinfo b/doc/manual/beyond-ansi.texinfo
index a0bffa2..c79ee95 100644 (file)
--- a/doc/manual/beyond-ansi.texinfo
+++ b/doc/manual/beyond-ansi.texinfo
@@ -7,56 +7,116 @@ ANSI standard. SBCL doesn't support as many extensions as CMUCL, but
 it still has quite a few.  @xref{Contributed Modules}.
 
 @menu
 it still has quite a few.  @xref{Contributed Modules}.
 
 @menu

-* Things Which Might Be In The Next ANSI Standard::  
+* Garbage Collection::          
+* Metaobject Protocol::         

 * Support For Unix::            
 * Customization Hooks for Users::  
 * Tools To Help Developers::    
 * Support For Unix::            
 * Customization Hooks for Users::  
 * Tools To Help Developers::    

-* Resolution of Name Conflicts::
+* Resolution of Name Conflicts::  

 * Stale Extensions::            
 * Efficiency Hacks::            
 @end menu
 
 * Stale Extensions::            
 * Efficiency Hacks::            
 @end menu
 

-@node  Things Which Might Be In The Next ANSI Standard
+@node  Garbage Collection

 @comment  node-name,  next,  previous,  up
 @comment  node-name,  next,  previous,  up

-@section Things Which Might Be In The Next ANSI Standard
-
-SBCL provides extensive support for calling external C code,
-@ref{Foreign Function Interface}.
+@section Garbage Collection

 
 SBCL provides additional garbage collection functionality not
 specified by ANSI. Weak pointers allow references to objects to be
 
 SBCL provides additional garbage collection functionality not
 specified by ANSI. Weak pointers allow references to objects to be

-maintained without keeping them from being GCed (garbage
-collected). And ``finalization'' hooks are available to cause code to
-be executed when an object has been GCed.
-@c <!-- FIXME: Actually documenting these would be good.:-| -->
-
-SBCL supports @dfn{Gray streams}, user-overloadable CLOS classes whose
-instances can be used as Lisp streams (e.g. passed as the first
-argument to @code{format}).  Additionally, the bundled contrib module
-@dfn{sb-simple-streams} implements a subset of the Franz Allegro
-simple-streams proposal.
-
-SBCL supports a MetaObject Protocol which is intended to be compatible
+maintained without keeping them from being garbage collected, and
+``finalization'' hooks are available to cause code to be executed when
+an object has been garbage collected. Additionally users can specify
+their own cleanup actions to be executed with garbage collection.
+
+@include fun-sb-ext-finalize.texinfo
+@include fun-sb-ext-cancel-finalization.texinfo
+@include fun-sb-ext-make-weak-pointer.texinfo
+@include fun-sb-ext-weak-pointer-value.texinfo
+@include var-sb-ext-star-after-gc-hooks-star.texinfo
+
+@node Metaobject Protocol
+@comment  node-name,  next,  previous,  up
+@section Metaobject Protocol
+
+SBCL supports a metaobject protocol which is intended to be compatible

 with AMOP; present exceptions to this (as distinct from current bugs)
 are:
 
 @itemize
   
 @item
 with AMOP; present exceptions to this (as distinct from current bugs)
 are:
 
 @itemize
   
 @item

-the abstract @code{metaobject} class is not present in the class
-hierarchy;
-  
-@item
-the @code{standard-object} and @code{funcallable-standard-object}
-classes are disjoint;
+@findex compute-effective-method
+@findex sb-mop:compute-effective-method
+@code{compute-effective-method} only returns one value, not two.
+
+There is no record of what the second return value was meant to
+indicate, and apparently no clients for it.

   
 @item
   
 @item

-@code{compute-effective-method} only returns one value, not two;
-  
+@findex ensure-generic-function
+@findex generic-function-declarations
+@findex sb-mop:generic-function-declarations
+the arguments @code{:declare} and @code{:declarations} to
+@code{ensure-generic-function} are both accepted, with the leftmost
+argument defining the declarations to be stored and returned by
+@code{generic-function-declarations}.
+
+Where AMOP specifies @code{:declarations} as the keyword argument to
+@code{ensure-generic-function}, the Common Lisp standard specifies
+@code{:declare}.  Portable code should use @code{:declare}.
+

 @item
 @item

-the system-supplied @code{:around} method for @code{compute-slots}
-specialized on @code{funcallable-standard-class} does not respect the
-requested order from a user-supplied primary method.
+@findex validate-superclass
+@findex finalize-inheritance
+@findex sb-mop:validate-superclass
+@findex sb-mop:finalize-inheritance
+@tindex standard-class
+@tindex funcallable-standard-class
+@tindex sb-mop:funcallable-standard-class
+@tindex function
+@findex sb-mop:class-prototype
+@findex class-prototype
+although SBCL obeys the requirement in AMOP for
+@code{validate-superclass} for @code{standard-class} and
+@code{funcallable-standard-class} to be compatible metaclasses, we
+impose an additional requirement at class finalization time: a class
+of metaclass @code{funcallable-standard-class} must have
+@code{function} in its superclasses, and a class of metaclass
+@code{standard-class} must not.
+
+@findex typep
+@findex class-of
+@findex subtypep
+At class finalization, a class prototype which is accessible by a
+standard mop function @code{sb-mop:class-prototype}.  The user can
+then ask whether this object is a @code{function} or not in several
+different ways: whether it is a function according to @code{typep};
+whether its @code{class-of} is @code{subtypep} @code{function}, or
+whether @code{function} appears in the superclasses of the class.  The
+additional consistency requirement comes from the desire to make all
+of these answers the same.
+
+The following class definitions are bad, and will lead to errors
+either immediately or if an instance is created:
+@lisp
+(defclass bad-object (funcallable-standard-object)
+  ()
+  (:metaclass standard-class))
+@end lisp
+@lisp
+(defclass bad-funcallable-object (standard-object)
+  ()
+  (:metaclass funcallable-standard-class))
+@end lisp
+The following definition is acceptable:
+@lisp
+(defclass mixin ()
+  ((slot :initarg slot)))
+(defclass funcallable-object (funcallable-standard-object mixin)
+  ()
+  (:metaclass funcallable-standard-class))
+@end lisp
+and leads to a class whose instances are funcallable and have one slot.

 
 @end itemize
 
 
 @end itemize
 

@@ -144,15 +204,15 @@ list.
 @section Efficiency Hacks
 
 The @code{sb-ext:purify} function causes SBCL first to collect all
 @section Efficiency Hacks
 
 The @code{sb-ext:purify} function causes SBCL first to collect all

-garbage, then to mark all uncollected objects as permanent, never
-again attempting to collect them as garbage. This can cause a large
-increase in efficiency when using a primitive garbage collector, or a
-more moderate increase in efficiency when using a more sophisticated
-garbage collector which is well suited to the program's memory usage
-pattern. It also allows permanent code to be frozen at fixed
-addresses, a precondition for using copy-on-write to share code
-between multiple Lisp processes. it is less important with modern
-generational garbage collectors.
+garbage, then to mark all uncollected objects as permanent, never again
+attempting to collect them as garbage. This can cause a large increase
+in efficiency when using a primitive garbage collector, or a more
+moderate increase in efficiency when using a more sophisticated garbage
+collector which is well suited to the program's memory usage pattern. It
+also allows permanent code to be frozen at fixed addresses, a
+precondition for using copy-on-write to share code between multiple Lisp
+processes.  This is less important with modern generational garbage
+collectors, but not all SBCL platforms use such a garbage collector.

 
 @include fun-sb-ext-purify.texinfo
 
 
 @include fun-sb-ext-purify.texinfo