0.9.4.56:
[sbcl.git] / doc / manual / beyond-ansi.texinfo
index fdf8b69..7960c08 100644 (file)
@@ -7,56 +7,86 @@ 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::  
 * 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
+@tindex metaobject
 the abstract @code{metaobject} class is not present in the class
 hierarchy;
   
 @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;
-  
-@item
+@findex compute-effective-method
+@findex sb-mop:compute-effective-method
 @code{compute-effective-method} only returns one value, not two;
   
 @item
 @code{compute-effective-method} only returns one value, not two;
   
 @item
+@findex compute-slots
+@findex sb-mop:compute-slots
+@tindex funcallable-standard-class 
+@tindex sb-mop:funcallable-standard-class 
 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.
 
 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.
 
+@item
+@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}.
+
+@item
+@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
+although we obey 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.
+
 @end itemize
 
 @node  Support For Unix
 @end itemize
 
 @node  Support For Unix
@@ -92,7 +122,7 @@ mechanisms as follows:
 @include fun-common-lisp-ed.texinfo
 @include var-sb-ext-star-ed-functions-star.texinfo
 
 @include fun-common-lisp-ed.texinfo
 @include var-sb-ext-star-ed-functions-star.texinfo
 
-@node  Tools To Help Developers
+@node Tools To Help Developers
 @comment  node-name,  next,  previous,  up
 @section Tools To Help Developers
 
 @comment  node-name,  next,  previous,  up
 @section Tools To Help Developers
 
@@ -105,6 +135,17 @@ accessed by typing @kbd{help} at the debugger prompt. @xref{Debugger}.
 Documentation for @code{inspect} is accessed by typing @kbd{help} at
 the @code{inspect} prompt.
 
 Documentation for @code{inspect} is accessed by typing @kbd{help} at
 the @code{inspect} prompt.
 
+@node Resolution of Name Conflicts
+@section Resolution of Name Conflicts
+
+The ANSI standard (section 11.1.1.2.5) requires that name conflicts in
+packages be resolvable in favour of any of the conflicting symbols.  In
+the interactive debugger, this is achieved by prompting for the symbol
+in whose favour the conflict should be resolved; for programmatic use,
+the @code{sb-ext:resolve-conflict} restart should be invoked with one
+argument, which should be a member of the list returned by the condition
+accessor @code{sb-ext:name-conflict-symbols}.
+
 @node Stale Extensions
 @comment  node-name,  next,  previous,  up
 @section Stale Extensions
 @node Stale Extensions
 @comment  node-name,  next,  previous,  up
 @section Stale Extensions
@@ -132,15 +173,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