[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
issue COMPILER-DIAGNOSTICS, version 2
- To: email@example.com
- Subject: issue COMPILER-DIAGNOSTICS, version 2
- From: firstname.lastname@example.org (Sandra J Loosemore)
- Date: Wed, 19 Oct 88 09:50:19 MDT
Version 1 of this issue went only to Dan Pierson, who is working on
the related issue GC-MESSAGES (which is going to include the NOTICE
condition type). There are some unresolved questions mentioned in the
discussion section, and comments are solicited....
References: CLtL p. 438-439
Condition System, Revision #18
Category: CLARIFICATION, ENHANCEMENT
Edit History: V1, 15 Oct 1988, Sandra Loosemore
V2, 19 Oct 1988, Sandra Loosemore (minor fixes)
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, CLtL does not specify what the return value from COMPILE-FILE
(1) Clarify that COMPILE-FILE is allowed to print messages indicating the
normal progress of the compilation.
(2) Clarify that both ERROR and WARNING conditions may be signalled within
COMPILE or COMPILE-FILE. Except for arbitrary errors which may occur
due to compile-time processing of (EVAL-WHEN (COMPILE) ...) forms or
macro expansion, ERRORs and WARNINGs may be signalled by the compiler
only in situations which are clearly documented in the standard. An
implementation may signal additional ERRORs and WARNINGs only in
conjunction with processing of nonstandard special forms supported as
an extension to Common Lisp by that implementation. All other
implementation-specific programming style diagnostics issued by
the compiler should be signalled as conditions of type NOTICE.
(3) Add a :HANDLER keyword argument to COMPILE-FILE, which is a condition
handler function which is to be used during compilation. If NIL or
not supplied, COMPILE-FILE is allowed to establish its own
implementation-specific condition handler, which may or may not cause
the debugger to be entered when errors occur. It is permissible for
the default error handler to attempt to recover from the error and
continue compiling the file.
(4) Specify that COMPILE-FILE returns the pathname for the output file if
it was able to successfully compile the input file. However, if
ERRORs occur and the compiler is able to recover and return normally,
it should return NIL to indicate unsuccessful completion.
(5) Clarify that COMPILE does not establish a condition handler. Instead,
it uses whatever condition handler has been established in the environment
from which it is called.
(1) This reflects current practice.
(2) Conditions such as syntax errors which are errors in the interpreter
remain errors in the compiler. Restricting implementations from
having their compilers signal random errors and warnings allows user
error handlers to know what kinds of conditions to expect.
(3) It is reasonable for the default handling of compiler errors not to
cause the debugger to be invoked. However, any error handler
established by COMPILE-FILE would override handlers established by the
user in the surrounding environment.
(4) This allows users to determine whether or not COMPILE-FILE is able to
actually compile the file successfully.
(5) This is to reflect the use of COMPILE-FILE as being more "batch"-oriented
and COMPILE as being more interactive. There is less motivation to have
COMPILE try to recover from errors without user interaction.
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.)
In Lucid Common Lisp, COMPILE-FILE invokes the debugger when it encounters
serious problems. COMPILE-FILE returns the pathname for the output file.
Both VaxLisp and Lucid normally print out a lot of informational messages
during compilation, including names of files, names of each function
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.
Users are given a way to detect and handle compilation errors.
Pierson has suggested removing item (1) of the proposal and instead
requiring the compiler not to print out any random informational
messages. We could define another kind of non-serious condition
(INFO?) to take care of trivia like file names and progress messages.
What do you implementors think about this?
This proposal, as it stands, doesn't propose to add any new conditions
specific to the compiler. We might consider introducing a
COMPILER-CONDITION that can be used in mixins with the other condition
types, so that error handlers can distinguish between errors signalled
by the compiler itself and errors signalled during macroexpansion or
The warnings and errors which can potentially be signalled during the
processing of standard special forms and macros need to be spelled out