doc/manual/intro.texinfo

   1 SBCL is a mostly-conforming implementation of the ANSI Common Lisp
   2 standard. This manual focuses on behavior which is specific to SBCL,
   3 not on behavior which is common to all implementations of ANSI Common
   4 Lisp.
   5
   6 @menu
   7 * More Common Lisp Information::
   8 * More SBCL Information::
   9 * Overview::
  10 @end menu
  11
  12 @node More Common Lisp Information
  13 @comment  node-name,  next,  previous,  up
  14 @section Sources of information about Common Lisp
  15
  16 Regardless of your ability level, two very useful resources for
  17 working with any implementation of Common Lisp are the SLIME
  18 package@footnote{Historically, the ILISP package at
  19 @uref{http://ilisp.cons.org/} provided similar functionality, but it
  20 does not support modern SBCL versions.}  for Emacs at
  21 @uref{http://www.common-lisp.net/project/slime} and the Common Lisp
  22 HyperSpec at
  23 @uref{http://www.lispworks.com/reference/HyperSpec/index.html}.
  24
  25 If you're not a programmer and you're trying to learn, many
  26 introductory Lisp books are available. However, we don't have any
  27 standout favorites. If you can't decide, try checking the Usenet
  28 @uref{news://comp.lang.lisp} FAQ for recent recommendations.
  29
  30 If you are an experienced programmer in other languages but need to
  31 learn about Lisp, three books stand out.
  32
  33 @itemize
  34
  35 @item
  36 @emph{ANSI Common Lisp}, by Paul Graham, will teach you
  37 about most of the language. (And later it might also be worth checking
  38 out @emph{On Lisp}, by the same author.)
  39
  40 @item
  41 @emph{Paradigms Of Artificial Intelligence
  42 Programming}, by Peter Norvig, also has some good information on
  43 general Common Lisp programming, and many nontrivial examples.
  44 Whether or not your work is AI, it's a very good book to look at.
  45
  46 @item
  47 Neither of the books above emphasizes CLOS, but @emph{Object-Oriented
  48 Programming In Common Lisp} by Sonya Keene does. Even if you're very
  49 knowledgeable about object oriented programming in the abstract, it's
  50 worth looking at this book if you want to do any OO in Common
  51 Lisp. Some abstractions in CLOS (especially multiple dispatch) go
  52 beyond anything you'll see in most OO systems, and there are a number
  53 of lesser differences as well. This book tends to help with the
  54 culture shock.
  55
  56 @end itemize
  57
  58
  59 @node More SBCL Information
  60 @comment  node-name,  next,  previous,  up
  61 @section Sources of more information about SBCL
  62
  63 Before you read this user manual, you should probably read two other
  64 things.
  65
  66 @itemize
  67
  68 @item
  69 You should know how to program in Common Lisp.  If you don't already
  70 know how, you should probably read a book on it.  @xref{More Common
  71 Lisp Information}.
  72
  73 @item
  74 The Unix ``man page'' for SBCL will tell you
  75 how to start the SBCL environment, so you can get to the classic
  76 ``hello, world'' level of knowledge. It's the file called
  77 @file{sbcl.1} in the SBCL distribution. If SBCL is installed on your
  78 system, you can read a formatted copy by executing the command
  79 @samp{man sbcl}.
  80
  81 @end itemize
  82
  83
  84 Besides this user manual and the Unix man page, some other
  85 SBCL-specific information is available:
  86
  87 @itemize
  88
  89 @item
  90 The SBCL home page at @uref{http://www.sbcl.org/} has some
  91 general information, plus links to mailing lists devoted to SBCL, and
  92 to archives of these mailing lists.
  93
  94 @item
  95 @findex help
  96 Documentation for non-ANSI extensions for various commands is
  97 available online from the SBCL executable itself. The extensions for
  98 functions which have their own command prompts (e.g. the debugger, and
  99 @code{inspect}) are documented in text available by typing
 100 @command{help} at their command prompts. The extensions for functions
 101 which don't have their own command prompt (such as @code{trace}) are
 102 described in their documentation strings, unless your SBCL was
 103 compiled with an option not to include documentation strings, in which
 104 case the doc strings are only readable in the source code.
 105
 106 @item
 107 Some low-level information describing the programming details of the
 108 conversion from CMUCL to SBCL is available in the
 109 @file{doc/FOR-CMUCL-DEVELOPERS} file in the SBCL
 110 distribution.
 111
 112 @end itemize
 113
 114
 115 @node Overview
 116 @comment  node-name,  next,  previous,  up
 117 @section History and Implementation
 118
 119 You can work productively with SBCL without knowing anything
 120 understanding anything about where it came from, how it is
 121 implemented, or how it extends the ANSI Common Lisp standard. However,
 122 a little knowledge can be helpful in order to understand error
 123 messages, to troubleshoot problems, to understand why some parts of
 124 the system are better debugged than others, and to anticipate which
 125 known bugs, known performance problems, and missing extensions are
 126 likely to be fixed, tuned, or added.
 127
 128 SBCL is descended from CMUCL, which is itself descended from Spice
 129 Lisp, including early implementations for the Mach operating system on
 130 the IBM RT, back in the 1980s. Some design decisions from that time are
 131 still reflected in the current implementation:
 132
 133 @itemize
 134
 135 @item
 136 The system expects to be loaded into a fixed-at-compile-time location
 137 in virtual memory, and also expects the location of all of its heap
 138 storage to be specified at compile time.
 139
 140 @item
 141 The system overcommits memory, allocating large amounts of address
 142 space from the system (often more than the amount of virtual memory
 143 available) and then failing if ends up using too much of the allocated
 144 storage.
 145
 146 @item
 147 The system is implemented as a C program which is responsible for
 148 supplying low-level services and loading a Lisp @file{.core}
 149 file.
 150
 151 @end itemize
 152
 153 @cindex Garbage Collection, generational
 154 SBCL also inherited some newer architectural features from CMUCL. The
 155 most important is that on some architectures it has a generational
 156 garbage collector (``GC''), which has various implications (mostly
 157 good) for performance. These are discussed in another chapter,
 158 @ref{Efficiency}.
 159
 160 SBCL has diverged from CMUCL in that SBCL is now essentially a
 161 ``compiler-only implementation'' of Common Lisp. This is a change in
 162 implementation strategy, taking advantage of the freedom ``any of these
 163 facilities might share the same execution strategy'' guaranteed in the
 164 ANSI specification section 3.1 (``Evaluation''). It does not mean SBCL
 165 can't be used interactively, and in fact the change is largely invisible
 166 to the casual user, since SBCL still can and does execute code
 167 interactively by compiling it on the fly. (It is visible if you know how
 168 to look, like using @code{compiled-function-p}; and it is visible in the
 169 way that that SBCL doesn't have many bugs which behave differently in
 170 interpreted code than in compiled code.) What it means is that in SBCL,
 171 the @code{eval} function only truly ``interprets'' a few easy kinds of
 172 forms, such as symbols which are @code{boundp}. More complicated forms
 173 are evaluated by calling @code{compile} and then calling @code{funcall}
 174 on 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 removed many CMUCL extensions, (e.g. IP networking, remote
 215 procedure call, Unix system interface, and X11 interface) from the
 216 core system.  Most of these are available as contributed modules
 217 (distributed with sbcl) or third-party modules instead.
 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