+@node Declarations
+@comment node-name, next, previous, up
+@subsection Declarations
+
+Declarations are generally treated as assertions. This general
+principle, and its implications, and the bugs which still keep the
+compiler from quite satisfying this principle, are discussed in
+@ref{Declarations as Assertions}.
+
+
+@node FASL Format
+@comment node-name, next, previous, up
+@subsection FASL Format
+
+SBCL fasl-format is binary compatible only with the exact SBCL version
+it was generated with. While this is obviously suboptimal, it has
+proven more robust than trying to maintain fasl compatibility across
+versions: accidentally breaking things is far too easy, and can lead
+to hard to diagnose bugs.
+
+The following snippet handles fasl recompilation automatically for
+ASDF-based systems, and makes a good candidate for inclusion in
+the user or system initialization file (@pxref{Initialization Files}.)
+
+@lisp
+(require :asdf)
+
+;;; If a fasl was stale, try to recompile and load (once).
+(defmethod asdf:perform :around ((o asdf:load-op)
+ (c asdf:cl-source-file))
+ (handler-case (call-next-method o c)
+ ;; If a fasl was stale, try to recompile and load (once).
+ (sb-ext:invalid-fasl ()
+ (asdf:perform (make-instance 'asdf:compile-op) c)
+ (call-next-method))))
+@end lisp
+
+
+@node Compiler-only Implementation
+@comment node-name, next, previous, up
+@subsection Compiler-only Implementation
+
+SBCL is essentially a compiler-only implementation of Common Lisp.
+That is, for all but a few special cases, @code{eval} creates a lambda
+expression, calls @code{compile} on the lambda expression to create a
+compiled function, and then calls @code{funcall} on the resulting
+function object. A more traditional interpreter is also available on
+default builds; it is usually only called internally. This is
+explicitly allowed by the ANSI standard, but leads to some oddities;
+e.g. at default settings, @code{functionp} and
+@code{compiled-function-p} are equivalent, and they collapse into the
+same function when SBCL is built without the interpreter.
+
+@node Defining Constants
+@comment node-name, next, previous, up
+@subsection Defining Constants
+@findex @cl{defconstant}
+
+SBCL is quite strict about ANSI's definition of @code{defconstant}.
+ANSI says that doing @code{defconstant} of the same symbol more than
+once is undefined unless the new value is @code{eql} to the old value.
+Conforming to this specification is a nuisance when the ``constant''
+value is only constant under some weaker test like @code{string=} or
+@code{equal}.
+
+It's especially annoying because, in SBCL, @code{defconstant} takes
+effect not only at load time but also at compile time, so that just
+compiling and loading reasonable code like
+@lisp
+(defconstant +foobyte+ '(1 4))
+@end lisp
+runs into this undefined behavior. Many implementations of Common Lisp
+try to help the programmer around this annoyance by silently accepting
+the undefined code and trying to do what the programmer probably
+meant.
+
+SBCL instead treats the undefined behavior as an error. Often such
+code can be rewritten in portable ANSI Common Lisp which has the
+desired behavior. E.g., the code above can be given an exactly defined
+meaning by replacing @code{defconstant} either with
+@code{defparameter} or with a customized macro which does the right
+thing, e.g.
+@lisp
+(defmacro define-constant (name value &optional doc)
+ `(defconstant ,name (if (boundp ',name) (symbol-value ',name) ,value)
+ ,@@(when doc (list doc))))
+@end lisp
+or possibly along the lines of the @code{defconstant-eqx} macro used
+internally in the implementation of SBCL itself. In circumstances
+where this is not appropriate, the programmer can handle the condition
+type @code{sb-ext:defconstant-uneql}, and choose either the
+@command{continue} or @command{abort} restart as appropriate.
+
+@node Style Warnings
+@comment node-name, next, previous, up
+@subsection Style Warnings