-Most extensions supported by CMU CL are not supported in SBCL,
-including Motif support, the Hemlock editor, search paths, the
-low-level Unix interface, the WIRE protocol, multithreading, various
-user-level macros and functions (e.g. LETF, ITERATE, MEMQ,
-REQUIRED-ARGUMENT), and many others.
-
-SBCL has retained some extensions from parent CMU CL. Many of the
-retained extensions are in these categories:
-.TP 3
-\--
-things which might be in the new ANSI spec, e.g. safe type
-declarations, weak pointers, finalization, foreign function
-interface to C, and Gray streams
-.TP 3
-\--
-things which are universally available in Unix scripting languages,
-e.g. RUN-PROGRAM and POSIX argv and getenv
-.TP 3
-\--
-hooks into the low level workings of the system which can be useful
-for debugging, e.g. requesting that a particular function be executed
-whenever GC occurs, or tuning compiler diagnostic output
-.TP 3
-\--
-unportable performance hacks, e.g. FREEZE-TYPE and PURIFY. For more
-information about these, look at the online documentation for symbols
-in the SB-EXT package, and look at the user manual.
-.PP
-
-There are also a few retained extensions which don't fall into any
-particular category, e.g. the ability to save running Lisp images as
-executable files.
-
-Some of the retained extensions have new names and/or different
-options than their CMU CL counterparts. For example, the SBCL function
-which saves a Lisp image to disk and kills the running process is
-called SAVE-LISP-AND-DIE instead of SAVE-LISP, and SBCL's
-SAVE-LISP-AND-DIE supports fewer keyword options than CMU CL's
-SAVE-LISP does.
-
-(Why doesn't SBCL support more extensions? Why drop all those nice
-extensions from CMU CL when the code already exists? This is a
-frequently asked question on the mailing list. In some cases, it's a
-design philosophy issue: arguably SBCL has done its job by supplying a
-stable FFI, and the right design decision is to move functionality
-derived from that, like socket support, into separate libraries,
-distributed as separate software packages by separate maintainers. In
-other cases it's a practical decision, hoping that focusing on a
-smaller number of things will let us do a better job on them. This is
-very much the case for multithreading: it's an important, valuable
-extension, but it's not easy to get right, and especially while SBCL
-is still working on basic ANSI compliance, difficult extensions aren't
-likely to be a priority.)
-
-.SH THE COMPILER
-
-SBCL is essentially a compiler-only implementation of Lisp. All
-nontrivial Lisp code is compiled to native machine code before being
-executed, even when the Lisp code is typed interactively at the
-"interpreter" prompt.
-
-SBCL inherits from CMU CL the "Python" native code compiler. (Though
-we've essentially dropped that name in order to avoid confusion with
-the scripting language also called Python.) This compiler is very
-clever about understanding the type system of Common Lisp and using it
-to optimize code, and about producing notes to let the user know when
-the compiler doesn't have enough type information to produce efficient
-code. It also tries (almost always successfully) to follow the unusual
-but very useful principle that "declarations are assertions", i.e.
-type declarations should be checked at runtime unless the user
-explicitly tells the system that speed is more important than safety.
-
-The CMU CL version of this compiler reportedly produces pretty good
-code for modern CPU architectures which have lots of registers, but
-its code for the X86 is marred by a lot of extra loads and stores to
-stack-based temporary variables. Because of this, and because of the
-extra levels of indirection in Common Lisp relative to C, the
-performance of SBCL isn't going to impress people who are impressed by
-small constant factors. However, even on the X86 it tends to be faster
-than byte interpreted languages (and can be a lot faster).
-
-The compiled code uses garbage collection to automatically
-manage memory. The garbage collector implementation varies considerably
-from CPU to CPU. In particular, on some CPUs the GC is nearly exact,
-while on others it's more conservative, and on some CPUs the GC
-is generational, while on others simpler stop and copy strategies
-are used.
-
-For more information about the compiler, see the user manual.
-
-.SH DOCUMENTATION
-
-Currently, the documentation for the system is
-.TP 3
-\--
-this man page
-.TP 3
-\--
-the user manual
-.TP 3
-\--
-doc strings and online help built into the SBCL executable
-.PP