issue COMPILER-DIAGNOSTICS, version 2

[sandra%defun@cs.utah.edu (Sandra J Loosemore)]

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....

-Sandra



Issue:		COMPILER-DIAGNOSTICS
References:	CLtL p. 438-439
		Condition System, Revision #18
		S:>KMP>cl-conditions.text.34
		Issue GC-MESSAGES
Category:	CLARIFICATION, ENHANCEMENT
Edit History:   V1, 15 Oct 1988, Sandra Loosemore
		V2, 19 Oct 1988, Sandra Loosemore (minor fixes)


Problem Description:

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
successfully compiled.

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
should be.


Proposal COMPILER-DIAGNOSTICS:USE-HANDLER:

(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.


Rationale:

(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.


Current Practice:

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
compiled, etc.


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
compile-time errors.


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.


Benefits:

Users are given a way to detect and handle compilation errors.


Discussion:

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
EVAL-WHEN processing.

The warnings and errors which can potentially be signalled during the
processing of standard special forms and macros need to be spelled out
in detail.
-------