From 24e6aa49b105bb608c04a4ccdc76fef7b5f838f2 Mon Sep 17 00:00:00 2001
From: William Harold Newman <william.newman@airmail.net>
Date: Sun, 23 Feb 2003 16:14:46 +0000
Subject: [PATCH] 0.7.12.55: 	doc fixes, some from #lisp... 	...emu
 pointed out where arg order stuff for :TEST functions 	
 is specified. 	...dan-b found a much-less-hackish !ENTITY
 for the manual.

---
 doc/compiler.sgml         |    4 ++--
 doc/sbcl-html.dsl         |   11 +---------
 doc/sbcl.1                |   49 ++++++++++++++++++++++-----------------------
 src/compiler/seqtran.lisp |   24 ++++------------------
 version.lisp-expr         |    2 +-
 5 files changed, 32 insertions(+), 58 deletions(-)

diff --git a/doc/compiler.sgml b/doc/compiler.sgml
index 18c797a..e66bca3 100644
--- a/doc/compiler.sgml
+++ b/doc/compiler.sgml
@@ -721,7 +721,7 @@ interpretation, and setting <parameter>safety</> less than
 compiler's decision whether to inline operations, which tend to
 increase the size of programs. Use the value <literal>0</> with
 caution, since it can cause the compiler to inline operations so
-promiscuously that the net effect is to slow the program by causing
+indiscriminately that the net effect is to slow the program by causing
 cache misses or swapping.</para>
 
 <!-- FIXME: old CMU CL compiler policy, should perhaps be adapted
@@ -790,7 +790,7 @@ _
 _\item[\code{space}] \cindex{space optimization quality}How much space
 _  the compiled code should take up.  Inline expansion is mostly
 _  inhibited when \code{space} is greater than \code{speed}.  A value
-_  of \code{0} enables promiscuous inline expansion.  Wide use of a
+_  of \code{0} enables indiscriminate inline expansion.  Wide use of a
 _  \code{0} value is not recommended, as it may waste so much space
 _  that run time is slowed.  \xlref{inline-expansion} for a discussion
 _  of inline expansion.
diff --git a/doc/sbcl-html.dsl b/doc/sbcl-html.dsl
index f31c4e9..82ca94d 100644
--- a/doc/sbcl-html.dsl
+++ b/doc/sbcl-html.dsl
@@ -19,18 +19,9 @@ at Carnegie Mellon University and released into the public domain. The
 software is in the public domain and is provided with absolutely no
 warranty. See the COPYING and CREDITS files for more information.
 
-KLUDGE: The ENTITY docbook.dsl command is hardwired to the appropriate
-location for my OpenBSD 2.9 system. There's got to be a more flexible
-way to do it, but I'm not enough of an SGML guru to begin to guess
-what it would be. (WHN 2001-10-15)
-
 --
 
- [<!ENTITY docbook.dsl
-           SYSTEM
-	   "/usr/local/share/sgml/docbook/dsssl/modular/html/docbook.dsl"
-	   CDATA
-	   dsssl>]>
+ [<!ENTITY docbook.dsl PUBLIC "-//Norman Walsh//DOCUMENT DocBook HTML Stylesheet//EN" CDATA dsssl>]>
 
 <style-sheet>
 <style-specification id="html" use="docbook">
diff --git a/doc/sbcl.1 b/doc/sbcl.1
index 2d83ea1..d7093b1 100644
--- a/doc/sbcl.1
+++ b/doc/sbcl.1
@@ -72,7 +72,7 @@ SBCL compiles Common Lisp to native code. (Even today, some 30 years
 after the MacLisp compiler, people will tell you that Lisp is an
 interpreted language. Ignore them.)
 
-SBCL aims for but has not yet reached compliance with the ANSI
+SBCL aims for but has not completely achieved compliance with the ANSI
 standard for Common Lisp. More information about this is available in
 the BUGS section below.
 
@@ -186,30 +186,30 @@ likely to be a priority.)
 
 .SH THE COMPILER
 
-SBCL is essentially a compiler-only implementation of Lisp. All
+SBCL is essentially a compiler-only implementation of Common Lisp. All
 nontrivial Lisp code is compiled to native machine code before being
 executed, even when the Lisp code is typed interactively at the
 "interpreter" prompt.
 
 SBCL inherits from CMU CL the "Python" native code compiler. (Though
-we've essentially dropped that name in order to avoid confusion with
-the scripting language also called Python.) This compiler is very
-clever about understanding the type system of Common Lisp and using it
-to optimize code, and about producing notes to let the user know when
-the compiler doesn't have enough type information to produce efficient
+we often avoid that name in order to avoid confusion with the
+scripting language also called Python.) This compiler is very clever
+about understanding the type system of Common Lisp and using it to
+optimize code, and about producing notes to let the user know when the
+compiler doesn't have enough type information to produce efficient
 code. It also tries (almost always successfully) to follow the unusual
 but very useful principle that "declarations are assertions", i.e.
 type declarations should be checked at runtime unless the user
 explicitly tells the system that speed is more important than safety.
 
-The CMU CL version of this compiler reportedly produces pretty good
-code for modern CPU architectures which have lots of registers, but
-its code for the X86 is marred by a lot of extra loads and stores to
-stack-based temporary variables. Because of this, and because of the
-extra levels of indirection in Common Lisp relative to C, the
-performance of SBCL isn't going to impress people who are impressed by
-small constant factors. However, even on the X86 it tends to be faster
-than byte interpreted languages (and can be a lot faster).
+The compiler reportedly produces pretty good code for modern CPU
+architectures which have lots of registers, but its code for the X86
+is marred by many extra loads and stores to stack-based temporary
+variables. Because of this, and because of the extra levels of
+indirection in Common Lisp relative to C, the performance of SBCL
+isn't going to impress people who are impressed by small constant
+factors. However, even on the X86 it tends to be faster than byte
+interpreted languages (and can be a lot faster).
 
 The compiled code uses garbage collection to automatically
 manage memory. The garbage collector implementation varies considerably
@@ -369,9 +369,8 @@ X86 (Linux, FreeBSD, and OpenBSD), Alpha (Linux, Tru64), PPC
 For information on other ongoing and possible ports, see the
 sbcl-devel mailing list, and/or the web site.
 
-SBCL requires on the order of 16Mb RAM to run on X86 systems, 
-though for all but the smallest programs would be happier with 32Mb
-or more.
+SBCL requires on the order of 16Mb RAM to run on X86 systems, though
+all but the smallest programs would be happier with 32Mb or more.
 
 .SH ENVIRONMENT
 
@@ -388,9 +387,9 @@ default.
 
 .SH FILES
 
-/usr/lib/sbcl.core and /usr/local/lib/sbcl.core are the standard
-locations for the standard SBCL core, unless overridden by the SBCL_HOME
-variable.
+/usr/lib/sbcl/sbcl.core and /usr/local/lib/sbcl/sbcl.core are the
+standard locations for the standard SBCL core, unless overridden by
+the SBCL_HOME variable.
 
 /etc/sbclrc and /usr/local/etc/sbclrc are the standard locations for
 system-wide SBCL initialization files, unless overridden by the
@@ -427,8 +426,8 @@ compiling a file containing
 (DECLAIM (FTYPE (FUNCTION (T) NULL) SOMETIMES))
 (DEFUN SOMETIMES (X) (ODDP X))
 (DEFUN FOO (X) (IF (SOMETIMES X) 'THIS-TIME 'NOT-THIS-TIME))
-then running (FOO 1) gives NOT-THIS-TIME, because the
-never compiled code to check the declaration.
+then running (FOO 1) gives NOT-THIS-TIME, because the compiler
+relied on the truth of the DECLAIM without checking it.
 
 Some things are implemented very inefficiently.
 .TP 3
@@ -501,7 +500,7 @@ handled specially by certain type expanders.)
 
 To report a bug, please send mail to the mailing lists sbcl-help or
 sbcl-devel. You can find the complete mailing list addresses on the
-web pages, <http://sbcl.sourceforge.net/>. (You may also find fancy
+web pages at <http://sbcl.sourceforge.net/>. (You may also find fancy
 SourceForge bug-tracking machinery there, but don't be fooled. As of
 2002-07-25 anyway, we don't actively monitor that machinery, and it
 exists only because we haven't been able to figure out how to turn
@@ -542,4 +541,4 @@ optional per-user customizable startup script (in user's home directory)
 
 Dozens of people have made substantial contributions to SBCL and its
 subsystems, and to the CMU CL system on which it was based, over the
-years. See the CREDITS file in the distribution.
+years. See the CREDITS file in the distribution for more information.
diff --git a/src/compiler/seqtran.lisp b/src/compiler/seqtran.lisp
index f92cd13..89b0494 100644
--- a/src/compiler/seqtran.lisp
+++ b/src/compiler/seqtran.lisp
@@ -807,26 +807,10 @@
 			      :important t)
   "expand inline"
   '(%find-position-if (let ((test-fun (%coerce-callable-to-fun test)))
-			;; I'm having difficulty believing I'm
-			;; reading it right, but as far as I can see,
-			;; the only guidance that ANSI gives for the
-			;; order of arguments to asymmetric tests is
-			;; the character-set dependent example from
-			;; the definition of FIND,
-			;;   (find #\d "here are some.." :test #'char>)
-			;;     => #\Space
-			;; (In ASCII, we have (CHAR> #\d #\SPACE)=>T.)
-			;; (Neither the POSITION definition page nor
-			;; section 17.2 ("Rules about Test Functions")
-			;; seem to consider the possibility of
-			;; asymmetry.)
-			;;
-			;; So, judging from the example, we want to
-			;; do (FUNCALL TEST-FUN ITEM I), because
-			;; (FUNCALL #'CHAR> #\d #\SPACE)=>T.
-			;;
-			;; -- WHN (whose attention was drawn to it by
-			;;         Alexey Dejneka's bug report/fix)
+			;; The order of arguments for asymmetric tests
+			;; (e.g. #'<, as opposed to order-independent
+			;; tests like #'=) is specified in the spec
+			;; section 17.2.1 -- the O/Zi stuff there.
 			(lambda (i)
 			  (funcall test-fun item i)))
 		      sequence
diff --git a/version.lisp-expr b/version.lisp-expr
index 4e02a79..f24a854 100644
--- a/version.lisp-expr
+++ b/version.lisp-expr
@@ -18,4 +18,4 @@
 ;;; versions, especially for internal versions off the main CVS
 ;;; branch, it gets hairier, e.g. "0.pre7.14.flaky4.13".)
 
-"0.7.12.54"
+"0.7.12.55"
-- 
1.7.10.4