X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=doc%2Fintro.sgml;h=0c4c1ee428ae54f2af48cf6cbb65b922a65cbd3f;hb=1462adfb42f8eceade5a5493d5ab91ee7838d423;hp=7c7fbcf6bc0b1e21ef706e739467e18749734a98;hpb=a8cd89bbf4c7a4a5316ad8ac1c758c4eaef094cd;p=sbcl.git
diff --git a/doc/intro.sgml b/doc/intro.sgml
index 7c7fbcf..0c4c1ee 100644
--- a/doc/intro.sgml
+++ b/doc/intro.sgml
@@ -6,7 +6,7 @@ specific to &SBCL;, not on behavior which is common to all
implementations of &ANSI; &CommonLisp;.
-Where To Go For More Information on &CommonLisp; in General
+Where To Go For More Information about &CommonLisp; in General
Regardless of your ability level, two very useful resources
for working with any implementation of
@@ -43,14 +43,13 @@ but need to learn about Lisp, three books stand out.
you'll see in most OO systems, and there are a number of lesser
differences as well. This book tends to help with the culture shock.
-
-Where To Go For More Information On &SBCL;
+Where To Go For More Information About &SBCL;
Before you read this user manual, you should probably read
two other things.
@@ -82,7 +81,7 @@ other &SBCL;-specific information is available:
at their command prompts. The extensions for functions which
don't have their own command prompt (like trace>
does) are described in their documentation strings,
- unless your &SBCL was compiled with an option not
+ unless your &SBCL; was compiled with an option not
to include documentation strings, in which case the doc strings
are only readable in the source code.
Some low-level information describing the
@@ -107,9 +106,9 @@ known bugs, known performance problems, and missing extensions are
likely to be fixed, tuned, or added.
&SBCL; is descended from &CMUCL;, which is itself descended from
-Spice Lisp. Early implementations for the Mach operating system on the
-IBM RT, back in the 1980s. Design decisions from that time are still
-reflected in the current implementation:
+Spice Lisp, including early implementations for the Mach operating
+system on the IBM RT, back in the 1980s. Design decisions from that
+time are still reflected in the current implementation:
The system expects to be loaded into a
fixed-at-compile-time location in virtual memory, and also expects
@@ -122,7 +121,8 @@ reflected in the current implementation:
A word is a 32-bit quantity. The system has been
ported to many processor architectures without altering this
basic principle. Some hacks allow the system to run on the Alpha
- chip (a 64-bit architecture) but the assumption that a word is
+ chip (a 64-bit architecture) but even there 32-bit words are
+ used. The assumption that a word is
32 bits wide is implicit in hundreds of places in the
system.
The system is implemented as a C program which is
@@ -160,8 +160,8 @@ debugging) do not work particularly well there. &SBCL; should be able
to improve in these areas (and has already improved in some other
areas), but it takes a while.
-The &SBCL; GC, like the GC on the X86 port of &CMUCL;, is
-conservative>. This means that it doesn't maintain a
+On the x86, &SBCL; like the X86 port of &CMUCL;, uses a
+conservative> GC. This means that it doesn't maintain a
strict separation between tagged and untagged data, instead treating
some untagged data (e.g. raw floating point numbers) as
possibly-tagged data and so not collecting any Lisp objects that they
@@ -182,15 +182,16 @@ running system with new versions. This quasi-build procedure can cause
various bizarre bootstrapping hangups, especially when a major change
is made to the system. It also makes the connection between the
current source code and the current executable more tenuous than in
-any other software system I'm aware of -- it's easy to accidentally
+other software systems -- it's easy to accidentally
build> a &CMUCL; system containing characteristics not
reflected in the current version of the source code.
Other major changes since the fork from &CMUCL; include
&SBCL; has dropped support for many &CMUCL; extensions,
- (e.g. remote procedure call, Unix system interface, and X11
- interface).
+ (e.g. IP networking, remote procedure call, Unix system interface, and X11
+ interface). Some of these are now available as contributed or
+ third-party modules.
&SBCL; has deleted or deprecated
some nonstandard features and code complexity which helped
efficiency at the price of maintainability. For example, the