-@node The Compiler, The Debugger, Introduction, Top
+@node The Compiler
@comment node-name, next, previous, up
@chapter The Compiler
* Open Coding and Inline Expansion::
@end menu
-@node Error Messages, Handling of Types, The Compiler, The Compiler
+@node Error Messages
@comment node-name, next, previous, up
@section Error Messages
@cindex Error messages, Compiler
* Read Errors::
@end menu
-@node The Parts of the Error Message, The Original and Actual Source, Error Messages, Error Messages
+@node The Parts of the Error Message
@comment node-name, next, previous, up
@subsection The Parts of the Error Message
processing path will also be omitted.
-@node The Original and Actual Source, Error Severity, The Parts of the Error Message, Error Messages
+@node The Original and Actual Source
@comment node-name, next, previous, up
@subsection The Original and Actual Source
explanation, so the compiler backed out one level.
-@node Error Severity, Errors During Macroexpansion, The Original and Actual Source, Error Messages
+@node Error Severity
@comment node-name, next, previous, up
@subsection Error Severity
@cindex Severity of compiler errors
improved.
-@node Errors During Macroexpansion, Read Errors, Error Severity, Error Messages
+@node Errors During Macroexpansion
@comment node-name, next, previous, up
@subsection Errors During Macroexpansion
@cindex Macroexpansion, errors during
@end example
-@node Read Errors, , Errors During Macroexpansion, Error Messages
+@node Read Errors
@comment node-name, next, previous, up
@subsection Read Errors
@cindex Read errors, compiler
@c _ -->
-@node Handling of Types, Compiler Policy, Error Messages, The Compiler
+@node Handling of Types
@comment node-name, next, previous, up
@section The Compiler's Handling of Types
@menu
-* Implementation Limitations::
* Type Errors at Compile Time::
* Precise Type Checking::
* Weakened Type Checking::
* Getting Existing Programs to Run::
+* Implementation Limitations::
@end menu
-@node Implementation Limitations, Type Errors at Compile Time, Handling of Types, Handling of Types
-@comment node-name, next, previous, up
-@subsection Implementation Limitations
-
-
-Ideally, the compiler would consider @emph{all} type declarations to
-be assertions, so that adding type declarations to a program, no
-matter how incorrect they might be, would @emph{never} cause undefined
-behavior. As of SBCL version 0.8.1, the compiler is known to fall
-short of this goal in two areas:
-
- @itemize
-
-@item
-@code{Proclaim}ed constraints on argument and result types of a
-function are supposed to be checked by the function. If the function
-type is proclaimed before function definition, type checks are
-inserted by the compiler, but the standard allows the reversed order,
-in which case the compiler will trust the declaration.
-
-@item
-The compiler cannot check types of an unknown number of values; if the
-number of generated values is unknown, but the number of consumed is
-known, only consumed values are checked.
-
-@item
-There are a few poorly characterized but apparently very uncommon
-situations where a type declaration in an unexpected location will be
-trusted and never checked by the compiler.
-
-@end itemize
-
-These are important bugs, but are not necessarily easy to fix, so they
-may, alas, remain in the system for a while.
-
-@node Type Errors at Compile Time, Precise Type Checking, Implementation Limitations, Handling of Types
+@node Type Errors at Compile Time
@comment node-name, next, previous, up
@subsection Type Errors at Compile Time
@cindex Compile time type errors
fragment that has spurious warnings.
-@node Precise Type Checking, Weakened Type Checking, Type Errors at Compile Time, Handling of Types
+@node Precise Type Checking
@comment node-name, next, previous, up
@subsection Precise Type Checking
@cindex Precise type checking
@code{member}, and other list-style type specifiers.
-@node Weakened Type Checking, Getting Existing Programs to Run, Precise Type Checking, Handling of Types
+@node Weakened Type Checking
@comment node-name, next, previous, up
@subsection Weakened Type Checking
@cindex Weakened type checking
nonexistent runtime checking.
-@node Getting Existing Programs to Run, , Weakened Type Checking, Handling of Types
+@node Getting Existing Programs to Run
@comment node-name, next, previous, up
@subsection Getting Existing Programs to Run
@cindex Existing programs, to run
@c <!-- FIXME: <xref>ND-variables, once we crib the text from the
@c CMU CL manual. -->
+@node Implementation Limitations
+@comment node-name, next, previous, up
+@subsection Implementation Limitations
+
+
+Ideally, the compiler would consider @emph{all} type declarations to
+be assertions, so that adding type declarations to a program, no
+matter how incorrect they might be, would @emph{never} cause undefined
+behavior. As of SBCL version 0.8.1, the compiler is known to fall
+short of this goal in two areas:
+
+ @itemize
+
+@item
+@code{Proclaim}ed constraints on argument and result types of a
+function are supposed to be checked by the function. If the function
+type is proclaimed before function definition, type checks are
+inserted by the compiler, but the standard allows the reversed order,
+in which case the compiler will trust the declaration.
+
+@item
+The compiler cannot check types of an unknown number of values; if the
+number of generated values is unknown, but the number of consumed is
+known, only consumed values are checked.
+
+@item
+There are a few poorly characterized but apparently very uncommon
+situations where a type declaration in an unexpected location will be
+trusted and never checked by the compiler.
+
+@end itemize
+
+These are important bugs, but are not necessarily easy to fix, so they
+may, alas, remain in the system for a while.
+
-@node Compiler Policy, Open Coding and Inline Expansion, Handling of Types, The Compiler
+@node Compiler Policy
@comment node-name, next, previous, up
@section Compiler Policy
@c _-->
-@node Open Coding and Inline Expansion, , Compiler Policy, The Compiler
+@node Open Coding and Inline Expansion
@comment node-name, next, previous, up
@section Open Coding and Inline Expansion
@cindex Open-coding