References: CLtL p. 438-439, 62, 69, 160, 161
Condition System, Revision #18
Category: CLARIFICATION, ENHANCEMENT
Edit History: V1, 15 Oct 1988, Sandra Loosemore
V2, 19 Oct 1988, Sandra Loosemore (minor fixes)
V3, 25 Oct 1988, Sandra Loosemore (input from Pitman & Gray)
V4, 01 Nov 1988, Sandra Loosemore (fix typos)
V5, 15 Dec 1988, Dan L. Pierson (new condition types)
V6, 15 Dec 1988, Sandra Loosemore (additions, fix wording)
V7, 16 Dec 1988, Dan L. Pierson (minor cleanup)
V8, 07 Jan 1989, Sandra Loosemore (expand discussion)
V9, 26 Jan 1989, Sandra Loosemore (simplify)
V10, 22 Mar 1989, Sandra Loosemore (error terminology)
V11, 11 Apr 1989, Kent Pitman (changes per X3J13)
V12, 21-Jun-89, Moon (changes to point 4 only: return a
status value from COMPILE also, make the status
value provide more detail)
V13, 22-Jun-89, Loosemore (fix one of the fixes)
V14, 04-Jul-89, Loosemore (amendments from June meeting)
Status: Passed V11 March 89
Passed V14 June 89
It is unclear whether various diagnostics issued by the compiler are
supposed to be true errors and warnings, or merely messages.
In some implementations, COMPILE-FILE handles even serious error
situations (such as syntax errors) by printing a message and then
trying to recover and continue compiling the rest of the file, rather
than by signalling an error. While this user interface style is just
as acceptable as invoking the debugger, it means that a normal return
from COMPILE-FILE does not necessarily imply that the file was
Many compilers issue warnings about programming style issues (such as
binding a variable that is never used but not declared IGNORE).
Sometimes these messages obscure warnings about more serious problems,
and there should be some way to differentiate between the two. For
example, it should be possible to suppress the style warnings.
Also, neither CLtL nor issue RETURN-VALUES-UNSPECIFIED states what the
return value from COMPILE-FILE should be.
(1) Introduce a new condition type, STYLE-WARNING, which is a subtype
(2) Clarify that ERROR and WARNING conditions may be signalled within
COMPILE or COMPILE-FILE, including arbitrary errors which may
occur due to compile-time processing of (EVAL-WHEN (COMPILE) ...)
forms or macro expansion.
Considering only those conditions signalled -by- the compiler (as
opposed to -within- the compiler),
(a) Conditions of type ERROR may be signalled by the compiler in
situations where the compilation cannot proceed without
file open errors
(b) Conditions of type WARNING may be signalled by the compiler in
situations where the standard explicitly states that a warning must,
should, or may be signalled; and where the compiler can determine
that a situation with undefined consequences or that would cause
an error to be signalled would result at runtime.
violation of type declarations
SETQ'ing or rebinding a constant defined with DEFCONSTANT
calls to built-in Lisp functions with wrong number of arguments
or malformed keyword argument lists
referencing a variable declared IGNORE
unrecognized declaration specifiers
(c) The compiler is permitted to signal diagnostics about matters of
programming style as conditions of type STYLE-WARNING. Although
STYLE-WARNINGs -may- be signalled in these situations, no
implementation is -required- to do so. However, if an
implementation does choose to signal a condition, that condition
will be of type STYLE-WARNING and will be signalled by a call to
the function WARN.
redefinition of function with different argument list
calls to function with wrong number of arguments
unreferenced local variables not declared IGNORE
declaration specifiers described in CLtL but ignored by
(3) State that both COMPILE and COMPILE-FILE are permitted (but not
required) to establish a handler for ERROR. For example, they
might issue a warning, and restart compilation from some
implementation-dependent point in order to let the compilation
proceed without manual intervention.
(4) Specify that COMPILE and COMPILE-FILE return three values. The first
value from COMPILE is not changed by this proposal. The first value
from COMPILE-FILE is the truename of the output file, or NIL if the
file could not be created.
The second value is NIL if no compiler diagnostics were issued, and
The third value is NIL if no compiler diagnostics other than style
warnings were issued. A non-NIL value indicates that there were
"serious" compiler diagnostics issued, or that other conditions of
type ERROR or WARNING (but not STYLE-WARNING) were signalled during
Introducing the STYLE-WARNING condition allows handlers to distinguish
between potentially serious problems and mere kibitzing on the part of
The second and third return values from COMPILE and COMPILE-FILE give
some indication of whether there were serious problems encountered in
compiling the file.
No implementation behaves exactly as specified in this proposal.
In VaxLisp, COMPILE-FILE handles most compile-time errors without
invoking the debugger. (It gives up on that top-level form and moves on
to the next one.) Instead of signalling errors or warnings, it simply
prints them out as messages.
In Lucid Common Lisp, COMPILE-FILE invokes the debugger when it encounters
serious problems. COMPILE-FILE returns the pathname for the output file.
Symbolics Genera usually tries to keep compiling when it encounters errors;
so does Symbolics Cloe.
On the TI Explorer, the compiler tries to catch most errors and turn
them into warnings (except for errors on opening a file), but the user
can change special variable COMPILER:WARN-ON-ERRORS to NIL if he wants
to enter the debugger on an error signalled during reading, macro
expansion, or compile-time evaluation. The true name of the output
file is returned as the first value. A second value indicates whether
any errors or warnings were reported.
IIM Common Lisp's compiler handles errors using a resignalling mechanism
similar to what is described here.
Cost to implementors:
The cost to implementors is not trivial but not particularly high. This
proposal tries to allow implementations considerable freedom in what
kinds of conditions the compiler must detect and how they are handled,
while still allowing users some reasonably portable ways to deal with
Cost to users:
This is a compatible extension. This proposal may cause users to see
some small differences in the user interface to the compiler, but
implementations already vary quite widely in their approaches. Some
users will probably have to make some minor changes to their code.
Adding the STYLE-WARNING type may cause conflicts with programs
already using that name.
Users are given a way to detect and handle compilation errors, which
would simplify the implementation of portable code-maintenance
utilities. The behavior of the compiler in error situations is made
more uniform across implementations.
The issue of whether the compiler may print normal progress messages
is discussed in detail in a separate issue, COMPILER-VERBOSITY.
Explicit calls to ERROR don't really justify warnings to be signalled
at compile-time, but we assume implementors have some common sense
about when it's appropriate to do so.