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