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