X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;ds=sidebyside;f=doc%2Fcompiler.sgml;h=18c797a990245240cde9175c0e8763135568632f;hb=6e7ae26173b40d635b94e81bc73f5c06d550de32;hp=39468a6b90d284ca82d8d95068438f24107e27a7;hpb=08307967c71c580058a503d46aa087cfefcf8c69;p=sbcl.git
diff --git a/doc/compiler.sgml b/doc/compiler.sgml
index 39468a6..18c797a 100644
--- a/doc/compiler.sgml
+++ b/doc/compiler.sgml
@@ -274,10 +274,10 @@ gives this error:
in: DEFUN FOO
(DO ((CURRENT L #) (# NIL)) (WHEN (EQ # E) (RETURN CURRENT)) )
-caught ERROR: (during macroexpansion)
-
-error in function LISP::FROB-DO-BODY:
- DO step variable is not a symbol: (ATOM CURRENT)
+caught ERROR:
+ (in macroexpansion of (DO # #))
+ (hint: For more precise location, try *BREAK-ON-SIGNALS*.)
+ DO step variable is not a symbol: (ATOM CURRENT)
@@ -447,7 +447,7 @@ warnings.
-Precise Type Checking>
+Precise Type Checking>
@@ -509,84 +509,14 @@ slots as precisely as possible. This often involves the use of
weakened type checking>, when the value for the
speed> optimization quality is greater than
safety>, and safety> is not 0>.
-The &CMUCL; manual still has a description of it, but the code no
-longer corresponds to the manual. It sounds like a good thing to have,
-and we might someday be able to restore it in &SBCL; but in the
-meantime, if you ask the compiler to optimize speed> to a
-higher level than safety>, your program is performing
-without a safety net, because &SBCL; may believe any or all type
-declarations without any runtime checking at all.
-
-
+The &CMUCL; manual still has a description of it, but even the CMU CL
+code no longer corresponds to the manual. Some of this partial safety
+checking lingers on in SBCL, but it's not a supported feature, and
+should not be relied on. If you ask the compiler to optimize
+speed> to a higher level than safety>,
+your program is performing without a safety net, because &SBCL; may
+at its option believe any or all type declarations with either partial
+or nonexistent runtime checking.
@@ -596,20 +526,21 @@ _ features it would be nice for SBCL to restore someday) -->
-Since &SBCL;'s compiler does much more comprehensive type
-checking than other Lisp compilers, &SBCL; will detect type errors in
-many programs that have been debugged using other compilers. These
-errors are mostly incorrect declarations, although compile-time type
-errors can find actual bugs if parts of the program have never been
-tested.
+Since &SBCL;'s compiler, like &CMUCL;'s compiler, does much more
+comprehensive type checking than most Lisp compilers, &SBCL; may
+detect type errors in programs that have been debugged using other
+compilers. These errors are mostly incorrect declarations, although
+compile-time type errors can find actual bugs if parts of the program
+have never been tested.Some incorrect declarations can only be detected by run-time
-type checking. It is very important to initially compile programs with
-full type checks and then test this version. After the checking
-version has been tested, then you can consider weakening or
-eliminating type checks. This applies even to previously
-debugged programs, because the &SBCL; compiler does much
-more type inference than other &CommonLisp; compilers, so an incorrect
+type checking. It is very important to initially compile a program
+with full type checks (high safety> optimization) and
+then test this safe version. After the checking version has been
+tested, then you can consider weakening or eliminating type checks.
+This applies even to previously debugged
+programs, because the &SBCL; compiler does much more type
+inference than other &CommonLisp; compilers, so an incorrect
declaration can do more damage.The most common problem is with variables whose constant initial
@@ -670,9 +601,7 @@ type of the result of evaluating a macro argument, then put a
`(the fixnum (1+ (the fixnum ,x))))
In this case, it would be stylistically preferable to change this
-macro back to a function and declare it inline. Macros have no
-efficiency advantage over inline functions when using the
-&SBCL; compiler.
+macro back to a function and declare it inline.
@@ -704,15 +633,15 @@ compiled using other compilers.
In this case, the fix is to weaken the type declaration to
(or fixnum null)>.
-Actually, this declaration is unnecessary
- unnecessary in &SBCL;, since it already knows position>
+Actually, this declaration is
+ unnecessary in &SBCL;, since it already knows that position>
returns a non-negative fixnum> or nil>.
Note that there is usually little performance penalty for weakening a
-declaration in this way. Any numeric operations in the body can still
-assume the variable is a fixnum>, since nil> is not a legal
-numeric argument. Another possible fix would be to say:
+declaration in this way. Any numeric operations in the body can still
+assume that the variable is a fixnum>, since nil>
+is not a legal numeric argument. Another possible fix would be to say:
(do ((pos 0 (position #\a string :start (1+ pos))))
((null pos))
@@ -727,10 +656,6 @@ variable in the loop body.
CMU CL manual. -->
-In summary, remember that all> values that a variable
-ever> has must be of the declared type, and that you
-should test using safe compilation options initially.
-
@@ -738,7 +663,7 @@ should test using safe compilation options initially.
Compiler Policy>
As of version 0.6.4, &SBCL; still uses most of the &CMUCL; code
-for compiler policy. Thi &CMUCL; code has many features and high-quality
+for compiler policy. The &CMUCL; code has many features and high-quality
documentation, but the two unfortunately do not match. So this area of
the compiler and its interface needs to be cleaned up. Meanwhile, here
is some rudimentary documentation on the current behavior of the
@@ -756,8 +681,8 @@ the speed> quality inhibits this notification. This can
be useful to suppress notes about code which is known to be
unavoidably inefficient. (For example, the compiler issues notes about
having to use generic arithmetic instead of fixnum arithmetic, which
-is not useful for code which truly can't guarantee that its arguments
-will always be fixnums.)
+is not helpful for code which by design supports arbitrary-sized
+integers instead of being limited to fixnums.)
The basic functionality of the optimize
inhibit-warnings> extension will probably be supported in all future
@@ -766,8 +691,8 @@ compiler and its interface are cleaned up. The current name is
misleading, because it mostly inhibits optimization notes, not
warnings. And making it an optimization quality is misleading, because
it shouldn't affect the resulting code at all. It may become a
-declaration identifier with a name like SB-EXT:INHIBIT-NOTES, so that
-what's currently written
+declaration identifier with a name like
+sb-ext:inhibit-notes>, so that what's currently written
(declaim (optimize (sb-ext:inhibit-warnings 2)))>
@@ -787,10 +712,10 @@ of types, array bounds, and so forth is suppressed.When safety> is less than speed>, any
and all type checks may be suppressed. At some point in the past,
&CMUCL; had a more nuanced
-interpretation of this. At some point in the future, &SBCL; may
-restore that interpretation, or something like it. Until then, setting
-safety> less than speed> may have roughly
-the same effect as setting safety> to zero.
+interpretation of this. However, &SBCL; doesn't support that
+interpretation, and setting safety> less than
+speed> may have roughly the same effect as setting
+safety> to zero.
The value of space> mostly influences the
compiler's decision whether to inline operations, which tend to