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. Some 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. This is a change in
 166 implementation strategy, taking advantage of the freedom ``any of these
 167 facilities might share the same execution strategy'' guaranteed in the
 168 ANSI specification section 3.1 (``Evaluation''). It does not mean SBCL
 169 can't be used interactively, and in fact the change is largely invisible
 170 to the casual user, since SBCL still can and does execute code
 171 interactively by compiling it on the fly. (It is visible if you know how
 172 to look, like using @code{compiled-function-p}; and it is visible in the
 173 way that that SBCL doesn't have many bugs which behave differently in
 174 interpreted code than in compiled code.) What it means is that in SBCL,
 175 the @code{eval} function only truly ``interprets'' a few easy kinds of
 176 forms, such as symbols which are @code{boundp}. More complicated forms
 177 are evaluated by calling @code{compile} and then calling @code{funcall}
 178 on the returned result.
 179
 180 The direct ancestor of SBCL is the x86 port of CMUCL. This port was in
 181 some ways the most cobbled-together of all the CMUCL ports, since a
 182 number of strange changes had to be made to support the register-poor
 183 x86 architecture. Some things (like tracing and debugging) do not work
 184 particularly well there. SBCL should be able to improve in these areas
 185 (and has already improved in some other areas), but it takes a while.
 186
 187 @cindex Garbage Collection, conservative
 188 On the x86 SBCL -- like the x86 port of CMUCL -- uses a
 189 @emph{conservative} GC. This means that it doesn't maintain a strict
 190 separation between tagged and untagged data, instead treating some
 191 untagged data (e.g. raw floating point numbers) as possibly-tagged
 192 data and so not collecting any Lisp objects that they point to. This
 193 has some negative consequences for average time efficiency (though
 194 possibly no worse than the negative consequences of trying to
 195 implement an exact GC on a processor architecture as register-poor as
 196 the X86) and also has potentially unlimited consequences for
 197 worst-case memory efficiency. In practice, conservative garbage
 198 collectors work reasonably well, not getting anywhere near the worst
 199 case. But they can occasionally cause odd patterns of memory usage.
 200
 201 The fork from CMUCL was based on a major rewrite of the system
 202 bootstrap process. CMUCL has for many years tolerated a very unusual
 203 ``build'' procedure which doesn't actually build the complete system
 204 from scratch, but instead progressively overwrites parts of a running
 205 system with new versions. This quasi-build procedure can cause various
 206 bizarre bootstrapping hangups, especially when a major change is made
 207 to the system. It also makes the connection between the current source
 208 code and the current executable more tenuous than in other software
 209 systems -- it's easy to accidentally ``build'' a CMUCL system
 210 containing characteristics not reflected in the current version of the
 211 source code.
 212
 213 Other major changes since the fork from CMUCL include
 214
 215 @itemize
 216
 217 @item
 218 SBCL has removed many CMUCL extensions, (e.g. IP networking, remote
 219 procedure call, Unix system interface, and X11 interface) from the
 220 core system.  Most of these are available as contributed modules
 221 (distributed with sbcl) or third-party modules instead.
 222
 223 @item
 224 SBCL has deleted or deprecated some nonstandard features and code
 225 complexity which helped efficiency at the price of
 226 maintainability. For example, the SBCL compiler no longer implements
 227 memory pooling internally (and so is simpler and more maintainable,
 228 but generates more garbage and runs more slowly), and various
 229 block-compilation efficiency-increasing extensions to the language
 230 have been deleted or are no longer used in the implementation of SBCL
 231 itself.
 232
 233 @end itemize