doc/intro.sgml

   1 <chapter id="intro"><title>Introduction</>
   2
   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>
   7
   8 <sect1 id="more-cl-info">
   9 <title>Where To Go For More Information about &CommonLisp; in General</title>
  10
  11 <para>Regardless of your ability level, two very useful resources
  12 for working with any implementation of
  13 &CommonLisp; are the
  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;
  17 HyperSpec</>.</para>
  18
  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>
  23
  24 <para>If you are an experienced programmer in other languages
  25 but need to learn about Lisp, three books stand out.
  26 <itemizedlist>
  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
  35     at.</para></listitem>
  36   <listitem><para>
  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.
  45   </para></listitem>
  46   <listitem><para></para></listitem>
  47 </itemizedlist>
  48 </para>
  49
  50 </sect1>
  51
  52 <sect1>
  53 <title>Where To Go For More Information About &SBCL;</title>
  54
  55 <para>Before you read this user manual, you should probably read
  56 two other things.
  57 <itemizedlist>
  58   <listitem><para>You should know how to program in &CommonLisp;.
  59     If you don't already know how, you should probably read a
  60     <link linkend="more-cl-info">book on it</>.</para></listitem>
  61   <listitem><para>The Unix <quote>man page</> for &SBCL; will tell you
  62     how to start the &SBCL; environment, so you can get to the
  63     classic <quote>hello, world</quote> level of knowledge. It's the file
  64     called <filename>sbcl.1</> in the &SBCL; distribution. If &SBCL; is
  65     installed on your system, you can read a formatted copy by
  66     executing the command <command>man sbcl</>.</para></listitem>
  67 </itemizedlist>
  68 </para>
  69
  70 <para>Besides this user manual and the Unix man page, some
  71 other &SBCL;-specific information is available:
  72 <itemizedlist>
  73   <listitem><para>The <ulink url="http://sbcl.sourceforge.net/">
  74     &SBCL; home page</ulink> has some general
  75     information, plus links to mailing lists devoted to &SBCL;,
  76     and to archives of these mailing lists.</para></listitem>
  77   <listitem><para>Documentation for non-&ANSI; extensions for
  78     various commands is available online from the &SBCL; executable
  79     itself. The extensions for functions which have their own
  80     command prompts (e.g. the debugger, and <function>inspect</>)
  81     are documented in text available by typing <userinput>help</>
  82     at their command prompts. The extensions for functions which
  83     don't have their own command prompt (like <function>trace</>
  84     does) are described in their documentation strings,
  85     unless your &SBCL was compiled with an option not
  86     to include documentation strings, in which case the doc strings
  87     are only readable in the source code.</para></listitem>
  88   <listitem><para>Some low-level information describing the
  89     programming details of the conversion from &CMUCL; to &SBCL;
  90     is available in the <filename>doc/FOR-CMUCL-DEVELOPERS</>
  91     file in the &SBCL; distribution.</para></listitem>
  92 </itemizedlist>
  93 </para>
  94
  95 </sect1>
  96
  97 <sect1 id="implementation">
  98 <title>Overview Of SBCL, How It Works And Where It Came From</>
  99
 100 <para>You can work productively with SBCL without knowing anything
 101 understanding anything about where it came from, how it is implemented,
 102 or how it extends the &ANSI; &CommonLisp; standard. However,
 103 a little knowledge can be helpful in order to understand error
 104 messages, to troubleshoot problems, to understand why some parts of
 105 the system are better debugged than others, and to anticipate which
 106 known bugs, known performance problems, and missing extensions are
 107 likely to be fixed, tuned, or added. </para>
 108
 109 <para>&SBCL; is descended from &CMUCL;, which is itself descended from
 110 Spice Lisp, including early implementations for the Mach operating
 111 system on the IBM RT, back in the 1980s. Design decisions from that
 112 time are still reflected in the current implementation:
 113 <itemizedlist>
 114   <listitem><para>The system expects to be loaded into a
 115     fixed-at-compile-time location in virtual memory, and also expects
 116     the location of all of its heap storage to be specified
 117     at compile time.</para></listitem>
 118   <listitem><para>The system overcommits memory, allocating large
 119     amounts of address space from the system (often more than
 120     the amount of virtual memory available) and then failing
 121     if ends up using too much of the allocated storage.</para></listitem>
 122   <listitem><para>A word is a 32-bit quantity. The system has been
 123     ported to many processor architectures without altering this
 124     basic principle. Some hacks allow the system to run on the Alpha
 125     chip (a 64-bit architecture) but even there 32-bit words are
 126     used. The assumption that a word is
 127     32 bits wide is implicit in hundreds of places in the
 128     system.</para></listitem>
 129   <listitem><para>The system is implemented as a C program which is
 130     responsible for supplying low-level services and loading a
 131     Lisp <quote>.core</quote> file.
 132   </para></listitem>
 133 </itemizedlist>
 134 </para>
 135
 136 <para>&SBCL; also inherited some newer architectural features from
 137 &CMUCL;. The most important is that it has a generational garbage
 138 collector (<quote>GC</>), which has various implications (mostly good)
 139 for performance. These are discussed in <link linkend="efficiency">
 140 another chapter</link>.</para>
 141
 142 <para>&SBCL; has diverged from &CMUCL; in that &SBCL; is now
 143 essentially a <quote>compiler-only implementation</quote> of
 144 &CommonLisp;. A &CommonLisp; implementation is permitted to implement
 145 both a compiler and an interpreter, and there's some special support
 146 in the standard (e.g. the distinction between <function>functionp</>
 147 and <function>compiled-function-p</>) to help support that. But &SBCL;
 148 has only a vestigial, rudimentary true interpreter. In &SBCL;, the
 149 <function>eval</> function only truly <quote>interprets</quote> a few
 150 special classes of forms, such as symbols which are
 151 <function>boundp</>. More complicated forms are evaluated by calling
 152 <function>compile</> and then calling <function>funcall</> on the
 153 returned result.
 154 </para>
 155
 156 <para>The direct ancestor of &SBCL; is the X86 port of &CMUCL;. This
 157 port was in some ways the most cobbled-together of all the &CMUCL;
 158 ports, since a number of strange changes had to be made to support the
 159 register-poor X86 architecture. Some things (like tracing and
 160 debugging) do not work particularly well there. &SBCL; should be able
 161 to improve in these areas (and has already improved in some other
 162 areas), but it takes a while.</para>
 163
 164 <para>On the x86, &SBCL; like the X86 port of &CMUCL;, uses a
 165 <emphasis>conservative</> GC. This means that it doesn't maintain a
 166 strict separation between tagged and untagged data, instead treating
 167 some untagged data (e.g. raw floating point numbers) as
 168 possibly-tagged data and so not collecting any Lisp objects that they
 169 point to. This has some negative consequences for average time
 170 efficiency (though possibly no worse than the negative consequences of
 171 trying to implement an exact GC on a processor architecture as
 172 register-poor as the X86) and also has potentially unlimited
 173 consequences for worst-case memory efficiency. In practice,
 174 conservative garbage collectors work reasonably well, not getting
 175 anywhere near the worst case. But they can occasionally cause
 176 odd patterns of memory usage.</para>
 177
 178 <para>The fork from &CMUCL; was based on a major rewrite of the system
 179 bootstrap process. &CMUCL; has for many years tolerated a very unusual
 180 <quote>build</> procedure which doesn't actually build the complete
 181 system from scratch, but instead progressively overwrites parts of a
 182 running system with new versions. This quasi-build procedure can cause
 183 various bizarre bootstrapping hangups, especially when a major change
 184 is made to the system. It also makes the connection between the
 185 current source code and the current executable more tenuous than in
 186 other software systems -- it's easy to accidentally
 187 <quote>build</> a &CMUCL; system containing characteristics not
 188 reflected in the current version of the source code.</para>
 189
 190 <para>Other major changes since the fork from &CMUCL; include
 191 <itemizedlist>
 192   <listitem><para>&SBCL; has dropped support for many &CMUCL; extensions,
 193     (e.g. remote procedure call, Unix system interface, and X11
 194     interface).</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>
 204 </itemizedlist>
 205 </para>
 206
 207 </sect1>
 208
 209 </chapter>