<function>with-compilation-unit</> is used to delay undefined
warnings.</para></listitem>
<listitem><para><computeroutput>in: DEFUN FOO</> This is the
- definition top-level form responsible for the error. It is
+ definition top level form responsible for the error. It is
obtained by taking the first two elements of the enclosing form
whose first element is a symbol beginning with <quote><literal>def</></>.
If there is no such enclosing <quote><literal>def</></> form, then the
<emphasis>original source</> form responsible for the error.
Original source means that the form directly appeared in the
original input to the compiler, i.e. in the lambda passed to
- <function>compile</> or in the top-level form read from the
+ <function>compile</> or in the top level form read from the
source file. In this example, the expansion of the <function>zoq</>
macro was responsible for the error.</para></listitem>
<listitem><para><computeroutput>--> ROQ PLOQ +</> This is the
<screen>in: DEFUN FOO
(DO ((CURRENT L #) (# NIL)) (WHEN (EQ # E) (RETURN CURRENT)) )
-caught ERROR: (during macroexpansion)
-
-error in function LISP::DO-DO-BODY:
- DO step variable is not a symbol: (ATOM CURRENT)</screen>
+caught ERROR:
+ (in macroexpansion of (DO # #))
+ (hint: For more precise location, try *BREAK-ON-SIGNALS*.)
+ DO step variable is not a symbol: (ATOM CURRENT)</screen>
</para>
</sect2>
_ \code{*print-length*} are used.
_ \end{defvar}
_
-_ \begin{defmac}{extensions:}{def-source-context}{%
+_ \begin{defmac}{extensions:}{define-source-context}{%
_ \args{\var{name} \var{lambda-list} \mstar{form}}}
_
_ This macro defines how to extract an abbreviated source context from
</sect2>
-<sect2><title>Precise Type Checking</>
+<sect2 id="precisetypechecking"><title>Precise Type Checking</>
<!--INDEX precise type checking-->
<!--INDEX {type checking}{precise}-->
<quote>weakened type checking</>, when the value for the
<parameter>speed</> optimization quality is greater than
<parameter>safety</>, and <parameter>safety</> is not <literal>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 <parameter>speed</> to a
-higher level than <parameter>safety</>, your program is performing
-without a safety net, because &SBCL; may believe any or all type
-declarations without any runtime checking at all.</para>
-
-<!-- (beginning of text adapted from out-of-date CMUCL manual, describing
-_ features it would be nice for SBCL to restore someday)
-_
-_ <para>When the value for the <parameter>speed</> optimization quality
-_ is greater than <parameter>safety</>, and <parameter>safety</> is not
-_ <literal>0</>, then type checking is weakened to reduce the speed and
-_ space penalty. In structure-intensive code this can double the speed,
-_ yet still catch most type errors. Weakened type checks provide a level
-_ of safety similar to that of <quote>safe</> code in other &CommonLisp;
-_ compilers.</para>
-_
-_ <para>A type check is weakened by changing the check to be for some
-_ convenient supertype of the asserted type. For example, <type>(integer
-_ 3 17)</> is changed to <type>fixnum</>, <type>(simple-vector 17)</> to
-_ <type>simple-vector</>, and structure types are changed to
-_ <type>structure-object</>. A test for a complex type like <type>(or node hunk
-_ (member :foo :bar :baz))</> will be omitted entirely (i.e., the type
-_ is weakened to <type>*</>.) If a precise check can be done for no
-_ extra cost, then no weakening is done.</para>
-_
-_ <para>Although weakened type checking is similar to type checking done
-_ by other compilers, it is sometimes safer and sometimes less safe.
-_ Weakened checks are done in the same places is precise checks, so all
-_ the preceding discussion about where checking is done still applies.
-_ Weakened checking is sometimes somewhat unsafe because although the
-_ check is weakened, the precise type is still input into type
-_ inference. In some contexts this will result in type inferences not
-_ justified by the weakened check, and hence deletion of some type
-_ checks that would be done by conventional compilers.</para>
-_
-_ <para>For example, if this code was compiled with weakened checks
-_
-_ <programlisting>(defstruct foo
-_ (a nil :type simple-string))
-_
-_ (defstruct bar
-_ (a nil :type single-float))
-_
-_ (defun myfun (x)
-_ (declare (type bar x))
-_ (* (bar-a x) 3.0))</programlisting>
-_
-_ and <function>myfun</> was passed a value of
-_ type <type>foo</>, then no type error would be
-_ signaled, and we would try to multiply a <type>simple-vector</> as
-_ though it were a <type>single-float</> (with unpredictable results.)
-_ This is because the check for <type>bar</> was weakened to
-_ <type>structure-object</>, yet when compiling the call to <type>bar-a</>, the
-_ compiler thinks it knows it has a <type>bar</>.</para>
-_
-_ <para>Note that normally even weakened type checks report the precise
-_ type in error messages. For example, if <function>myfun</>'s
-_ <type>bar</> check is weakened to <type>structure-object</>, and the argument
-_ is <literal>nil</>, then the error will be:
-_
-_ <screen>Type-error in MYFUN:
-_ NIL is not of type BAR</screen>
-_
-_ However, there is some speed and space cost for signaling a precise
-_ error, so the weakened type is reported if the <parameter>speed</>
-_ optimization quality is <literal>3</> or <parameter>debug</>
-_ quality is less than <literal>1</>:
-_
-_ <screen>Type-error in MYFUN:
-_ NIL is not of type STRUCTURE-OBJECT</screen>
-_
-_ </para>
-_
-_ (end of text adapted from out-of-date CMUCL manual, describing
-_ features it would be nice for SBCL to restore someday) -->
+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
+<parameter>speed</> to a higher level than <parameter>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.</para>
</sect2>
<!--INDEX {compatibility with other Lisps}
(should also have an entry in the non-&ANSI;-isms section)-->
-<para>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.</para>
+<para>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.</para>
<para>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. <emphasis>This applies even to previously
-debugged programs,</emphasis> 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 <parameter>safety</> optimization) and
+then test this safe version. After the checking version has been
+tested, then you can consider weakening or eliminating type checks.
+<emphasis>This applies even to previously debugged
+programs,</emphasis> because the &SBCL; compiler does much more type
+inference than other &CommonLisp; compilers, so an incorrect
declaration can do more damage.</para>
<para>The most common problem is with variables whose constant initial
`(the fixnum (1+ (the fixnum ,x))))</programlisting>
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.
<!--FIXME: <xref>inline-expansion</>, once we crib the
relevant text from the CMU CL manual.-->
</para>
<para>In this case, the fix is to weaken the type declaration to
<type>(or fixnum null)</>.
-<footnote><para>Actually, this declaration is unnecessary
- unnecessary in &SBCL;, since it already knows <function>position</>
+<footnote><para>Actually, this declaration is
+ unnecessary in &SBCL;, since it already knows that <function>position</>
returns a non-negative <type>fixnum</> or <literal>nil</>.
</para></footnote>
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 <type>fixnum</>, since <literal>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 <type>fixnum</>, since <literal>nil</>
+is not a legal numeric argument. Another possible fix would be to say:
<programlisting>(do ((pos 0 (position #\a string :start (1+ pos))))
((null pos))
CMU CL manual. -->
</para>
-<para>In summary, remember that <emphasis>all</> values that a variable
-<emphasis>ever</> has must be of the declared type, and that you
-should test using safe compilation options initially.</para>
-
</sect2>
</sect1>
<sect1 id="compiler-policy"><title>Compiler Policy</>
<para>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
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.)</para>
+is not helpful for code which by design supports arbitrary-sized
+integers instead of being limited to fixnums.)</para>
<note><para>The basic functionality of the <parameter>optimize
inhibit-warnings</> extension will probably be supported in all future
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
+<parameter>sb-ext:inhibit-notes</>, so that what's currently written
<programlisting>(declaim (optimize (sb-ext:inhibit-warnings 2)))</>
<para>When <parameter>safety</> is less than <parameter>speed</>, any
and all type checks may be suppressed. At some point in the past,
&CMUCL; had <link linkend="weakened-type-checking">a more nuanced
-interpretation of this.</link> At some point in the future, &SBCL; may
-restore that interpretation, or something like it. Until then, setting
-<parameter>safety</> less than <parameter>speed</> may have roughly
-the same effect as setting <parameter>safety</> to zero.</para>
+interpretation of this</link>. However, &SBCL; doesn't support that
+interpretation, and setting <parameter>safety</> less than
+<parameter>speed</> may have roughly the same effect as setting
+<parameter>safety</> to zero.</para>
<para>The value of <parameter>space</> mostly influences the
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
_\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.
projects / sbcl.git / blobdiff