-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