-To run SBCL, type "sbcl" at the command line with no arguments. (SBCL
-understands command line arguments, but you probably won't need to use
-them unless you're a fairly advanced user, in which case you should
-read the COMMAND LINE SYNTAX section, below.) You should see some
-startup messages, then a prompt ("*"). Type a Lisp expression at the
-prompt, and SBCL will read it, execute it, print the result,
-give you another prompt, and wait for your next input. E.g.
- * (+ 1 2 3)
- 6
- *
-
-Many people like to run SBCL, like other Lisp systems, as a subprocess
-under Emacs. The Emacs "ilisp" mode provides many convenient features,
-like command line editing, tab completion, and various kinds of
-coupling between Common Lisp source files and the interactive SBCL
-subprocess.
-
-.SH OVERVIEW
-
-SBCL aims for but has not reached ANSI compliance.
-
-SBCL compiles Common Lisp to native code, and is essentially a
-"compiler-only" implementation of the ANSI standard. (Unlike earlier
-versions of SBCL, byte compilation is no longer supported, and there
-is only a vestigial interpreter. Thus, in particular,
-COMPILED-FUNCTION-P is always equal to FUNCTIONP.)
-
-SBCL uses a generational conservative garbage collector for some ports,
-and a simple stop-and-copy garbage collector for other ports.
-
-SBCL also includes some non-ANSI extensions, notably
- * Lispy extensions:
- ** CMU-CL-style safe implementation of type declarations:
- "Declarations are assertions."
- ** source level debugger
- ** profiler
- ** saving the state of the running SBCL process, producing a
- "core" file which can be restarted later
- ** Gray streams (overloadable CLOS classes whose instances can
- be used wherever ANSI streams can be used)
- ** weak pointers and finalization (which have unfortunately
- suffered from at least some code rot, e.g. weak hash tables
- don't work)
- * system interface extensions:
- ** calling out to C code (a.k.a. FFI, foreign function interface)
- ** some simple support for operations with a "scripting language"
- flavor, e.g. reading POSIX argc and argv, or executing a
- subprogram
-
-.SH DIFFERENCES FROM CMU CL
-
-SBCL can be built from scratch using a plain vanilla ANSI Common Lisp
-system and a C compiler, and all of its properties are specified by
-the version of the source code that it was created from. (This clean
-bootstrappability was the immediate motivation for forking off of the
-CMU CL development tree.) A variety of internal implementation
-differences are motivated by this.
-
-Maintenance work in SBCL since the fork has diverged in various
-details from the maintenance work in CMU CL. E.g. as of 2001-04-12,
-SBCL was more ANSI-compliant than CMU CL in various details such as
-support for PRINT-OBJECT and DESCRIBE-OBJECT, and SBCL's compiler was
-substantially better than CMU CL's at optimizing operations on
-non-simple vectors.
-
-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 support,
-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. 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. a list of functions to be run whenever GC occurs,
-or parameters to modify compiler diagnostic output
-.TP 3
-\--
-unportable performance hacks, e.g. TRULY-THE, FREEZE-TYPE, and PURIFY
-.PP
-
-There are also a few retained extensions which don't fall into
-any particular category, e.g.
-.TP 3
-\--
-the ability to save running Lisp images as executable files
-.PP
-
-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 it is called
-SAVE-LISP-AND-DIE instead of SAVE-LISP, and it supports fewer keyword
-options than CMU CL's SAVE-LISP.
-
-(Why doesn't SBCL support more extensions? Why the hell did I (WHN)
-drop all those nice extensions from CMU CL when the code already
-exists? This is a frequently asked question on the mailing list. The
-answer is that they're hard to maintain, and I have enough on my hands
-already. Also, in the case of some big and unquestionably useful
-extensions, like sockets and Motif, I think that SBCL has done its job
-by supplying the FFI, and that people who need, and understand, and
-are motivated to maintain the functionality should supply it as a
-separate library, which I'd be happy to distribute or link to on the
-SBCL home page. Finally, in the case of multithreading, I do think it
-belongs in the new ANSI spec, and it'd be a good feature to have, but
-I didn't think the CMU CL implementation was sufficiently mature, and
-it's such a complicated and far-reaching extension that I thought that
-trying to fix it would interfere with the more urgent task of getting
-basic ANSI support up to speed.)
-
-.SH THE COMPILER
-
-As noted above, SBCL is essentially a compiler-only implementation of
-Lisp, with all nontrivial code being implemented by compilation, even
-when you type it interactively at the "interpreter" prompt.