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 Where To Go For More Information about Common Lisp in General
  19
  20 Regardless of your ability level, two very useful resources for
  21 working with any implementation of Common Lisp are the ILISP package
  22 for Emacs at @uref{http://ilisp.cons.org} and the Common Lisp HyperSpec
  23 at @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 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 Where To Go For 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://sbcl.sourceforge.net/} 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 Documentation for non-ANSI extensions for various commands is
  96 available online from the SBCL executable itself. The extensions for
  97 functions which have their own command prompts (e.g. the debugger, and
  98 @code{inspect}) are documented in text available by typing
  99 @command{help} at their command prompts. The extensions for functions
 100 which don't have their own command prompt (like @code{trace} does) are
 101 described in their documentation strings, unless your SBCL was
 102 compiled with an option not to include documentation strings, in which
 103 case the doc strings are only readable in the source code.
 104
 105 @item
 106 Some low-level information describing the programming details of the
 107 conversion from CMUCL to SBCL is available in the
 108 @file{doc/FOR-CMUCL-DEVELOPERS} file in the SBCL
 109 distribution.
 110
 111 @end itemize
 112
 113
 114 @node Overview
 115 @comment  node-name,  next,  previous,  up
 116 @section Overview Of SBCL, How It Works And Where It Came From
 117
 118 You can work productively with SBCL without knowing anything
 119 understanding anything about where it came from, how it is
 120 implemented, or how it extends the ANSI Common Lisp standard. However,
 121 a little knowledge can be helpful in order to understand error
 122 messages, to troubleshoot problems, to understand why some parts of
 123 the system are better debugged than others, and to anticipate which
 124 known bugs, known performance problems, and missing extensions are
 125 likely to be fixed, tuned, or added.
 126
 127 SBCL is descended from CMUCL, which is itself descended from Spice
 128 Lisp, including early implementations for the Mach operating system on
 129 the IBM RT, back in the 1980s. Design decisions from that time are
 130 still reflected in the current implementation:
 131
 132 @itemize
 133
 134 @item
 135 The system expects to be loaded into a fixed-at-compile-time location
 136 in virtual memory, and also expects the location of all of its heap
 137 storage to be specified at compile time.
 138
 139 @item
 140 The system overcommits memory, allocating large amounts of address
 141 space from the system (often more than the amount of virtual memory
 142 available) and then failing if ends up using too much of the allocated
 143 storage.
 144
 145 @item
 146 A word is a 32-bit quantity. The system has been ported to many
 147 processor architectures without altering this basic principle. Some
 148 hacks allow the system to run on the Alpha chip (a 64-bit
 149 architecture) but even there 32-bit words are used. The assumption
 150 that a word is 32 bits wide is implicit in hundreds of places in the
 151 system.
 152
 153 @item
 154 The system is implemented as a C program which is responsible for
 155 supplying low-level services and loading a Lisp @file{.core}
 156 file.
 157
 158 @end itemize
 159
 160 SBCL also inherited some newer architectural features from CMUCL. The
 161 most important is that on some architectures it has a generational
 162 garbage collector (``GC''), which has various implications (mostly
 163 good) for performance. These are discussed another chapter,
 164 @ref{Efficiency}.
 165
 166 SBCL has diverged from CMUCL in that SBCL is now essentially a
 167 ``compiler-only implementation'' of Common Lisp. A Common Lisp
 168 implementation is permitted to implement both a compiler and an
 169 interpreter, and there's some special support in the standard
 170 (e.g. the distinction between @code{functionp} and
 171 @code{compiled-function-p}) to help support that. But SBCL has only a
 172 vestigial, rudimentary true interpreter. In SBCL, the @code{eval}
 173 function only truly ``interprets'' a few special classes of forms,
 174 such as symbols which are @code{boundp}. More complicated forms are
 175 evaluated by calling @code{compile} and then calling @code{funcall} on
 176 the returned result.
 177
 178
 179 The direct ancestor of SBCL is the X86 port of CMUCL. This port was in
 180 some ways the most cobbled-together of all the CMUCL ports, since a
 181 number of strange changes had to be made to support the register-poor
 182 X86 architecture. Some things (like tracing and debugging) do not work
 183 particularly well there. SBCL should be able to improve in these areas
 184 (and has already improved in some other areas), but it takes a while.
 185
 186 On the x86, SBCL like the X86 port of CMUCL, uses a
 187 @emph{conservative} GC. This means that it doesn't maintain a strict
 188 separation between tagged and untagged data, instead treating some
 189 untagged data (e.g. raw floating point numbers) as possibly-tagged
 190 data and so not collecting any Lisp objects that they point to. This
 191 has some negative consequences for average time efficiency (though
 192 possibly no worse than the negative consequences of trying to
 193 implement an exact GC on a processor architecture as register-poor as
 194 the X86) and also has potentially unlimited consequences for
 195 worst-case memory efficiency. In practice, conservative garbage
 196 collectors work reasonably well, not getting anywhere near the worst
 197 case. But they can occasionally cause odd patterns of memory usage.
 198
 199 The fork from CMUCL was based on a major rewrite of the system
 200 bootstrap process. CMUCL has for many years tolerated a very unusual
 201 ``build'' procedure which doesn't actually build the complete system
 202 from scratch, but instead progressively overwrites parts of a running
 203 system with new versions. This quasi-build procedure can cause various
 204 bizarre bootstrapping hangups, especially when a major change is made
 205 to the system. It also makes the connection between the current source
 206 code and the current executable more tenuous than in other software
 207 systems -- it's easy to accidentally ``build'' a CMUCL system
 208 containing characteristics not reflected in the current version of the
 209 source code.
 210
 211 Other major changes since the fork from CMUCL include
 212
 213 @itemize
 214
 215 @item
 216 SBCL has dropped support for many CMUCL extensions, (e.g. IP
 217 networking, remote procedure call, Unix system interface, and X11
 218 interface).  Most of these are now available as contributed or
 219 third-party modules.
 220
 221 @item
 222 SBCL has deleted or deprecated some nonstandard features and code
 223 complexity which helped efficiency at the price of
 224 maintainability. For example, the SBCL compiler no longer implements
 225 memory pooling internally (and so is simpler and more maintainable,
 226 but generates more garbage and runs more slowly), and various
 227 block-compilation efficiency-increasing extensions to the language
 228 have been deleted or are no longer used in the implementation of SBCL
 229 itself.
 230
 231 @end itemize