-@node Introduction, The Compiler, Top, Top
+@node Introduction
@comment node-name, next, previous, up
@chapter Introduction
Lisp.
@menu
-* More Common Lisp Information::
-* More SBCL Information::
-* Overview::
+* More Common Lisp Information::
+* More SBCL Information::
+* Overview::
@end menu
-@node More Common Lisp Information, More SBCL Information, Introduction, Introduction
+@node More Common Lisp Information
@comment node-name, next, previous, up
-@section Where To Go For More Information about Common Lisp in General
+@section Sources of information about Common Lisp
Regardless of your ability level, two very useful resources for
-working with any implementation of Common Lisp are the ILISP package
-for Emacs at @uref{http://ilisp.cons.org} and the Common Lisp HyperSpec
-at @uref{http://www.lispworks.com/reference/HyperSpec/index.html}.
+working with any implementation of Common Lisp are the SLIME
+package@footnote{Historically, the ILISP package at
+@uref{http://ilisp.cons.org/} provided similar functionality, but it
+does not support modern SBCL versions.} for Emacs at
+@uref{http://www.common-lisp.net/project/slime} and the Common Lisp
+HyperSpec at
+@uref{http://www.lispworks.com/reference/HyperSpec/index.html}.
If you're not a programmer and you're trying to learn, many
introductory Lisp books are available. However, we don't have any
standout favorites. If you can't decide, try checking the Usenet
-comp.lang.lisp FAQ for recent recommendations.
+@uref{news://comp.lang.lisp} FAQ for recent recommendations.
If you are an experienced programmer in other languages but need to
learn about Lisp, three books stand out.
@end itemize
-@node More SBCL Information, Overview, More Common Lisp Information, Introduction
+@node More SBCL Information
@comment node-name, next, previous, up
-@section Where To Go For More Information About SBCL
+@section Sources of more information about SBCL
Before you read this user manual, you should probably read two other
things.
@itemize
@item
-The SBCL home page at @uref{http://sbcl.sourceforge.net/} has some
+The SBCL home page at @uref{http://www.sbcl.org/} has some
general information, plus links to mailing lists devoted to SBCL, and
to archives of these mailing lists.
@item
+@findex help
Documentation for non-ANSI extensions for various commands is
available online from the SBCL executable itself. The extensions for
functions which have their own command prompts (e.g. the debugger, and
@code{inspect}) are documented in text available by typing
@command{help} at their command prompts. The extensions for functions
-which don't have their own command prompt (like @code{trace} does) are
+which don't have their own command prompt (such as @code{trace}) are
described in their documentation strings, unless your SBCL was
compiled with an option not to include documentation strings, in which
case the doc strings are only readable in the source code.
@end itemize
-@node Overview, , More SBCL Information, Introduction
+@node Overview
@comment node-name, next, previous, up
-@section Overview Of SBCL, How It Works And Where It Came From
+@section History and Implementation
You can work productively with SBCL without knowing anything
understanding anything about where it came from, how it is
SBCL is descended from CMUCL, which is itself descended from Spice
Lisp, including early implementations for the Mach operating system on
-the IBM RT, back in the 1980s. Design decisions from that time are
+the IBM RT, back in the 1980s. Some design decisions from that time are
still reflected in the current implementation:
@itemize
storage.
@item
-A word is a 32-bit quantity. The system has been ported to many
-processor architectures without altering this basic principle. Some
-hacks allow the system to run on the Alpha chip (a 64-bit
-architecture) but even there 32-bit words are used. The assumption
-that a word is 32 bits wide is implicit in hundreds of places in the
-system.
-
-@item
The system is implemented as a C program which is responsible for
supplying low-level services and loading a Lisp @file{.core}
file.
@end itemize
-
+
+@cindex Garbage Collection, generational
SBCL also inherited some newer architectural features from CMUCL. The
most important is that on some architectures it has a generational
garbage collector (``GC''), which has various implications (mostly
-good) for performance. These are discussed another chapter,
+good) for performance. These are discussed in another chapter,
@ref{Efficiency}.
SBCL has diverged from CMUCL in that SBCL is now essentially a
-``compiler-only implementation'' of Common Lisp. A Common Lisp
-implementation is permitted to implement both a compiler and an
-interpreter, and there's some special support in the standard
-(e.g. the distinction between @code{functionp} and
-@code{compiled-function-p}) to help support that. But SBCL has only a
-vestigial, rudimentary true interpreter. In SBCL, the @code{eval}
-function only truly ``interprets'' a few special classes of forms,
-such as symbols which are @code{boundp}. More complicated forms are
-evaluated by calling @code{compile} and then calling @code{funcall} on
-the returned result.
+``compiler-only implementation'' of Common Lisp. This is a change in
+implementation strategy, taking advantage of the freedom ``any of these
+facilities might share the same execution strategy'' guaranteed in the
+ANSI specification section 3.1 (``Evaluation''). It does not mean SBCL
+can't be used interactively, and in fact the change is largely invisible
+to the casual user, since SBCL still can and does execute code
+interactively by compiling it on the fly. (It is visible if you know how
+to look, like using @code{compiled-function-p}; and it is visible in the
+way that that SBCL doesn't have many bugs which behave differently in
+interpreted code than in compiled code.) What it means is that in SBCL,
+the @code{eval} function only truly ``interprets'' a few easy kinds of
+forms, such as symbols which are @code{boundp}. More complicated forms
+are evaluated by calling @code{compile} and then calling @code{funcall}
+on the returned result.
-
-The direct ancestor of SBCL is the X86 port of CMUCL. This port was in
+The direct ancestor of SBCL is the x86 port of CMUCL. This port was in
some ways the most cobbled-together of all the CMUCL ports, since a
number of strange changes had to be made to support the register-poor
-X86 architecture. Some things (like tracing and debugging) do not work
+x86 architecture. Some things (like tracing and debugging) do not work
particularly well there. SBCL should be able to improve in these areas
(and has already improved in some other areas), but it takes a while.
-On the x86, SBCL like the X86 port of CMUCL, uses a
+@cindex Garbage Collection, conservative
+On the x86 SBCL -- like the x86 port of CMUCL -- uses a
@emph{conservative} GC. This means that it doesn't maintain a strict
separation between tagged and untagged data, instead treating some
untagged data (e.g. raw floating point numbers) as possibly-tagged
@itemize
@item
-SBCL has dropped support for many CMUCL extensions, (e.g. IP
-networking, remote procedure call, Unix system interface, and X11
-interface). Most of these are now available as contributed or
-third-party modules.
+SBCL has removed many CMUCL extensions, (e.g. IP networking, remote
+procedure call, Unix system interface, and X11 interface) from the
+core system. Most of these are available as contributed modules
+(distributed with sbcl) or third-party modules instead.
@item
SBCL has deleted or deprecated some nonstandard features and code
projects / sbcl.git / blobdiff