-SBCL, like most (maybe all?) implementations of Common Lisp on
-stock hardware, has trouble
-passing floating point numbers around efficiently, because a floating
-point number, plus a few extra bits to identify its type,
-is larger than a machine word. (Thus, they get "boxed" in
-heap-allocated storage, causing GC overhead.) Within
-a single compilation unit,
-or when doing built-in operations like SQRT and AREF,
-or some special operations like structure slot accesses,
-this is avoidable: see the user manual for some
-efficiency hints. But for general function calls across
-the boundaries of compilation units, passing the result of
-a floating point calculation
-as a function argument (or returning a floating point
-result as a function value) is a fundamentally slow operation.
-.PP
-
-There are still some nagging pre-ANSIisms, notably
-.TP 3
---
-The ANSI-recommended idiom for creating a function which is only
-sometimes expanded inline,
-(DECLAIM (INLINE F))
-(DEFUN F ...)
-(DECLAIM (NOTINLINE F)),
-doesn't do what you'd expect. (Instead, you have to declare the
-function as SB-EXT:MAYBE-INLINE to get the desired effect.)
-.TP 3
-\--
-There are several nonconforming bits of type syntax. E.g. (1) The type
-FOO is strictly equivalent to (FOO), so e.g. the type OR is treated as
-the type (OR), i.e. the empty type. This is the way that the ancestral
-code worked, and even though ANSI specifically forbids it, it hasn't
-been fixed yet. (2) The symbol * is the name of a type similar to T.
-(It's used as part of the implementation of compound types like (ARRAY
-* 1) and (CONS * *). In a strict ANSI implementation, * would not be
-the name of a type, but instead just a symbol which is recognized and
-handled specially by certain type expanders.)
+SBCL, like most (maybe all?) implementations of Common Lisp on stock
+hardware, has trouble passing floating point numbers around
+efficiently, because a floating point number, plus a few extra bits to
+identify its type, is larger than a machine word. (Thus, they get
+"boxed" in heap-allocated storage, causing GC overhead.) Within a
+single compilation unit, or when doing built-in operations like
+\f(CRSQRT\fR and \f(CRAREF\fR, or some special operations like
+structure slot accesses, this is avoidable: see the user manual for
+some efficiency hints. But for general function calls across the
+boundaries of compilation units, passing the result of a floating
+point calculation as a function argument (or returning a floating
+point result as a function value) is a fundamentally slow operation.