doc/manual/intro.texinfo

   1 @node Introduction
   2 @comment  node-name,  next,  previous,  up
   3 @chapter Introduction
   4
   5 SBCL is a mostly-conforming implementation of the ANSI Common Lisp
   6 standard. This manual focuses on behavior which is specific to SBCL,
   7 not on behavior which is common to all implementations of ANSI Common
   8 Lisp.
   9
  10 @menu
  11 * More Common Lisp Information::
  12 * More SBCL Information::
  13 * Overview::
  14 @end menu
  15
  16 @node More Common Lisp Information
  17 @comment  node-name,  next,  previous,  up
  18 @section Sources of information about Common Lisp
  19
  20 Regardless of your ability level, two very useful resources for
  21 working with any implementation of Common Lisp are the SLIME
  22 package@footnote{Historically, the ILISP package at
  23 @uref{http://ilisp.cons.org/} provided similar functionality, but it
  24 does not support modern SBCL versions.}  for Emacs at
  25 @uref{http://www.common-lisp.net/project/slime} and the Common Lisp
  26 HyperSpec at
  27 @uref{http://www.lispworks.com/reference/HyperSpec/index.html}.
  28
  29 If you're not a programmer and you're trying to learn, many
  30 introductory Lisp books are available. However, we don't have any
  31 standout favorites. If you can't decide, try checking the Usenet
  32 @uref{news://comp.lang.lisp} FAQ for recent recommendations.
  33
  34 If you are an experienced programmer in other languages but need to
  35 learn about Lisp, three books stand out.
  36
  37 @itemize
  38
  39 @item
  40 @emph{ANSI Common Lisp}, by Paul Graham, will teach you
  41 about most of the language. (And later it might also be worth checking
  42 out @emph{On Lisp}, by the same author.)
  43
  44 @item
  45 @emph{Paradigms Of Artificial Intelligence
  46 Programming}, by Peter Norvig, also has some good information on
  47 general Common Lisp programming, and many nontrivial examples.
  48 Whether or not your work is AI, it's a very good book to look at.
  49
  50 @item
  51 Neither of the books above emphasizes CLOS, but @emph{Object-Oriented
  52 Programming In Common Lisp} by Sonya Keene does. Even if you're very
  53 knowledgeable about object oriented programming in the abstract, it's
  54 worth looking at this book if you want to do any OO in Common
  55 Lisp. Some abstractions in CLOS (especially multiple dispatch) go
  56 beyond anything you'll see in most OO systems, and there are a number
  57 of lesser differences as well. This book tends to help with the
  58 culture shock.
  59
  60 @end itemize
  61
  62
  63 @node More SBCL Information
  64 @comment  node-name,  next,  previous,  up
  65 @section Sources of more information about SBCL
  66
  67 Before you read this user manual, you should probably read two other
  68 things.
  69
  70 @itemize
  71
  72 @item
  73 You should know how to program in Common Lisp.  If you don't already
  74 know how, you should probably read a book on it.  @xref{More Common
  75 Lisp Information}.
  76
  77 @item
  78 The Unix ``man page'' for SBCL will tell you
  79 how to start the SBCL environment, so you can get to the classic
  80 ``hello, world'' level of knowledge. It's the file called
  81 @file{sbcl.1} in the SBCL distribution. If SBCL is installed on your
  82 system, you can read a formatted copy by executing the command
  83 @samp{man sbcl}.
  84
  85 @end itemize
  86
  87
  88 Besides this user manual and the Unix man page, some other
  89 SBCL-specific information is available:
  90
  91 @itemize
  92
  93 @item
  94 The SBCL home page at @uref{http://www.sbcl.org/} has some
  95 general information, plus links to mailing lists devoted to SBCL, and
  96 to archives of these mailing lists.
  97
  98 @item
  99 @findex help
 100 Documentation for non-ANSI extensions for various commands is
 101 available online from the SBCL executable itself. The extensions for
 102 functions which have their own command prompts (e.g. the debugger, and
 103 @code{inspect}) are documented in text available by typing
 104 @command{help} at their command prompts. The extensions for functions
 105 which don't have their own command prompt (such as @code{trace}) are
 106 described in their documentation strings, unless your SBCL was
 107 compiled with an option not to include documentation strings, in which
 108 case the doc strings are only readable in the source code.
 109
 110 @item
 111 Some low-level information describing the programming details of the
 112 conversion from CMUCL to SBCL is available in the
 113 @file{doc/FOR-CMUCL-DEVELOPERS} file in the SBCL
 114 distribution.
 115
 116 @end itemize
 117
 118
 119 @node Overview
 120 @comment  node-name,  next,  previous,  up
 121 @section History and Implementation
 122
 123 You can work productively with SBCL without knowing anything
 124 understanding anything about where it came from, how it is
 125 implemented, or how it extends the ANSI Common Lisp standard. However,
 126 a little knowledge can be helpful in order to understand error
 127 messages, to troubleshoot problems, to understand why some parts of
 128 the system are better debugged than others, and to anticipate which
 129 known bugs, known performance problems, and missing extensions are
 130 likely to be fixed, tuned, or added.
 131
 132 SBCL is descended from CMUCL, which is itself descended from Spice
 133 Lisp, including early implementations for the Mach operating system on
 134 the IBM RT, back in the 1980s. Design decisions from that time are
 135 still reflected in the current implementation:
 136
 137 @itemize
 138
 139 @item
 140 The system expects to be loaded into a fixed-at-compile-time location
 141 in virtual memory, and also expects the location of all of its heap
 142 storage to be specified at compile time.
 143
 144 @item
 145 The system overcommits memory, allocating large amounts of address
 146 space from the system (often more than the amount of virtual memory
 147 available) and then failing if ends up using too much of the allocated
 148 storage.
 149
 150 @item
 151 The system is implemented as a C program which is responsible for
 152 supplying low-level services and loading a Lisp @file{.core}
 153 file.
 154
 155 @end itemize
 156
 157 @cindex Garbage Collection, generational
 158 SBCL also inherited some newer architectural features from CMUCL. The
 159 most important is that on some architectures it has a generational
 160 garbage collector (``GC''), which has various implications (mostly
 161 good) for performance. These are discussed in another chapter,
 162 @ref{Efficiency}.
 163
 164 SBCL has diverged from CMUCL in that SBCL is now essentially a
 165 ``compiler-only implementation'' of Common Lisp. A Common Lisp
 166 implementation is permitted to implement both a compiler and an
 167 interpreter, and there's some special support in the standard
 168 (e.g. the distinction between @code{functionp} and
 169 @code{compiled-function-p}) to help support that. But SBCL has only a
 170 vestigial, rudimentary true interpreter. In SBCL, the @code{eval}
 171 function only truly ``interprets'' a few special classes of forms,
 172 such as symbols which are @code{boundp}. More complicated forms are
 173 evaluated by calling @code{compile} and then calling @code{funcall} on
 174 the returned result.
 175
 176 The direct ancestor of SBCL is the x86 port of CMUCL. This port was in
 177 some ways the most cobbled-together of all the CMUCL ports, since a
 178 number of strange changes had to be made to support the register-poor
 179 x86 architecture. Some things (like tracing and debugging) do not work
 180 particularly well there. SBCL should be able to improve in these areas
 181 (and has already improved in some other areas), but it takes a while.
 182
 183 @cindex Garbage Collection, conservative
 184 On the x86 SBCL -- like the x86 port of CMUCL -- uses a
 185 @emph{conservative} GC. This means that it doesn't maintain a strict
 186 separation between tagged and untagged data, instead treating some
 187 untagged data (e.g. raw floating point numbers) as possibly-tagged
 188 data and so not collecting any Lisp objects that they point to. This
 189 has some negative consequences for average time efficiency (though
 190 possibly no worse than the negative consequences of trying to
 191 implement an exact GC on a processor architecture as register-poor as
 192 the X86) and also has potentially unlimited consequences for
 193 worst-case memory efficiency. In practice, conservative garbage
 194 collectors work reasonably well, not getting anywhere near the worst
 195 case. But they can occasionally cause odd patterns of memory usage.
 196
 197 The fork from CMUCL was based on a major rewrite of the system
 198 bootstrap process. CMUCL has for many years tolerated a very unusual
 199 ``build'' procedure which doesn't actually build the complete system
 200 from scratch, but instead progressively overwrites parts of a running
 201 system with new versions. This quasi-build procedure can cause various
 202 bizarre bootstrapping hangups, especially when a major change is made
 203 to the system. It also makes the connection between the current source
 204 code and the current executable more tenuous than in other software
 205 systems -- it's easy to accidentally ``build'' a CMUCL system
 206 containing characteristics not reflected in the current version of the
 207 source code.
 208
 209 Other major changes since the fork from CMUCL include
 210
 211 @itemize
 212
 213 @item
 214 SBCL has dropped support for many CMUCL extensions, (e.g. IP
 215 networking, remote procedure call, Unix system interface, and X11
 216 interface).  Most of these are now available as contributed or
 217 third-party modules.
 218
 219 @item
 220 SBCL has deleted or deprecated some nonstandard features and code
 221 complexity which helped efficiency at the price of
 222 maintainability. For example, the SBCL compiler no longer implements
 223 memory pooling internally (and so is simpler and more maintainable,
 224 but generates more garbage and runs more slowly), and various
 225 block-compilation efficiency-increasing extensions to the language
 226 have been deleted or are no longer used in the implementation of SBCL
 227 itself.
 228
 229 @end itemize