X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=doc%2Fmanual%2Fcompiler.texinfo;h=0c03d9874a29bf33bb2f3850ba3e9ddc386bdb0a;hb=11b5ac86a98f058fe0375b0a707c6ef9e24590c9;hp=546f817dd44ca1c56ace2c9426ac1f33776751b2;hpb=2d996b6c1f64a2a8f7515629bba134da0d0f0d32;p=sbcl.git

diff --git a/doc/manual/compiler.texinfo b/doc/manual/compiler.texinfo
index 546f817..0c03d98 100644
--- a/doc/manual/compiler.texinfo
+++ b/doc/manual/compiler.texinfo
@@ -11,11 +11,12 @@ naive translation. Efficiency issues are sufficiently varied and
 separate that they have their own chapter, @ref{Efficiency}.
 
 @menu
-* Diagnostic Messages::         
+* Diagnostic Messages::
 * Handling of Types::           
 * Compiler Policy::             
 * Compiler Errors::             
 * Open Coding and Inline Expansion::  
+* Interpreter::
 @end menu
 
 @node  Diagnostic Messages
@@ -83,6 +84,9 @@ controlled via the alist
 
 @include var-sb-ext-star-compiler-print-variable-alist-star.texinfo
 
+For information about muffling warnings signaled outside of the
+compiler, see @ref{Customization Hooks for Users}.
+
 @c <!-- FIXME: How much control over error messages is in SBCL?
 @c      _     How much should be? How much of this documentation should
 @c      _     we save or adapt? 
@@ -125,7 +129,7 @@ controlled via the alist
 @comment  node-name,  next,  previous,  up
 @subsection Diagnostic Severity
 @cindex Severity of compiler messages
-@cindex compiler diagnostic severity
+@cindex Compiler Diagnostic Severity
 @tindex error
 @tindex warning
 @tindex style-warning
@@ -152,8 +156,8 @@ to the @code{sb-ext:compiler-note}, and is used for problems which are
 too mild for the standard condition classes, typically hints about how
 efficiency might be improved. The @code{sb-ext:code-deletion-note}, a
 subtype of @code{compiler-note}, is signalled when the compiler
-deletes user-supplied code, usually after proving that the code in
-question is unreachable.
+deletes user-supplied code after proving that the code in question is
+unreachable.
 
 Future work for SBCL includes expanding this hierarchy of types to
 allow more fine-grained control over emission of diagnostic messages.
@@ -389,7 +393,7 @@ This message is not saying ``there is a problem somewhere in this
 @node The Processing Path
 @comment  node-name,  next,  previous,  up
 @subsubsection The Processing Path
-@cindex Processing path
+@cindex Processing Path
 @cindex Macroexpansion
 @cindex Source-to-source transformation
 
@@ -452,11 +456,10 @@ one level.
 @comment  node-name,  next,  previous,  up
 @section Handling of Types
 
-The most unusual features of the SBCL compiler (which is very
-similar to the original CMUCL compiler, also known as @dfn{Python})
-is its unusually sophisticated understanding of the Common Lisp type
-system and its unusually conservative approach to the implementation
-of type declarations.
+One of the most important features of the SBCL compiler (similar to
+the original CMUCL compiler, also known as @dfn{Python}) is its fairly
+sophisticated understanding of the Common Lisp type system and its
+conservative approach to the implementation of type declarations.
 
 These two features reward the use of type declarations throughout
 development, even when high performance is not a concern. Also, as
@@ -489,21 +492,28 @@ involving the @code{satisfies} type specifier.
 @subsection Declarations as Assertions
 @findex safety
 
-The SBCL compiler treats type declarations differently from most
-other Lisp compilers. Under default compilation policy the compiler
-doesn't blindly believe type declarations, but considers them
-assertions about the program that should be checked: all type
-declarations that have not been proven to always hold are asserted at
-runtime.
+The SBCL compiler treats type declarations differently from most other
+Lisp compilers. Under default compilation policy the compiler doesn't
+blindly believe type declarations, but considers them assertions about
+the program that should be checked: all type declarations that have
+not been proven to always hold are asserted at runtime.
 
 @quotation
 @emph{Remaining bugs in the compiler's handling of types unfortunately
 provide some exceptions to this rule, see @ref{Implementation
-Limitations}).}
+Limitations}.}
 @end quotation
 
-There are three type checking policies available in SBCL,
-selectable via @code{optimize} declarations.
+CLOS slot types form a notable exception. Types declared using the
+@code{:type} slot option in @code{defclass} are asserted if and only
+if the class was defined in @emph{safe code} and the slot access
+location is in @emph{safe code} as well. This laxness does not pose
+any internal consistency issues, as the CLOS slot types are not
+available for the type inferencer, nor do CLOS slot types provide any
+efficiency benefits.
+
+There are three type checking policies available in SBCL, selectable
+via @code{optimize} declarations.
 
 @table @strong
 
@@ -512,21 +522,28 @@ selectable via @code{optimize} declarations.
 
 @item Full Type Checks
 All declarations are considered assertions to be checked at runtime,
-and all type checks are precise.
+and all type checks are precise. The default compilation policy
+provides full type checks.
 
-Used when @code{(>= safety (max speed space compilation-speed)}. The
-default compilation policy provides full type checks.
+Used when @code{(or (>= safety 2) (>= safety speed 1))}.
 
 @item Weak Type Checks
-Any or all type declarations may be believed without runtime
-assertions, and assertions that are done may be imprecise.
+Declared types may be simplified into faster to check supertypes: for
+example, @code{(or (integer -17 -7) (integer 7 17))} is simplified
+into @code{(integer -17 17)}.
+
+@strong{Note}: it is relatively easy to corrupt the heap when weak
+type checks are used if the program contains type-errors.
 
-Used when @code{(< 0 safety (max speed space compilation-speed)}.
+Used when @code{(and (< safety 2) (< safety speed))}
 
 @item No Type Checks
 All declarations are believed without assertions. Also disables
 argument count and array bounds checking.
 
+@strong{Note}: any type errors in code where type checks are not
+performed are liable to corrupt the heap.
+
 Used when @code{(= safety 0)}.
 
 @end table
@@ -1016,8 +1033,8 @@ character position and gives up on the entire source file.
 @comment  node-name,  next,  previous,  up
 @section Open Coding and Inline Expansion
 @cindex Open-coding
-@cindex inline expansion
-@cindex static functions
+@cindex Inline expansion
+@cindex Static functions
 
 Since Common Lisp forbids the redefinition of standard functions, the
 compiler can have special knowledge of these standard functions
@@ -1088,3 +1105,20 @@ open-coded. Even when not open-coded, a call to a standard function
 may be transformed into a different function call (as in the last
 example) or compiled as @emph{static call}. Static function call uses
 a more efficient calling convention that forbids redefinition.
+
+@node  Interpreter
+@comment  node-name,  next,  previous,  up
+@section Interpreter
+@cindex Interpreter
+@vindex sb-ext:*evaluator-mode*
+
+By default SBCL implements @code{eval} by calling the native code
+compiler. SBCL also includes an interpreter for use in special cases
+where using the compiler is undesirable, for example due to compilation
+overhead. Unlike in some other Lisp implementations, in SBCL interpreted
+code is not safer or more debuggable than compiled code.
+
+Switching between the compiler and the interpreter is done using the
+special variable @code{sb-ext:*evaluator-mode*}. As of 0.9.17, valid
+values for @code{sb-ext:*evaluator-mode*} are @code{:compile} and
+@code{:interpret}.