Re: issue COMPILER-DIAGNOSTICS, version 4

[David N Gray <Gray@DSG.csc.ti.com>]

>     (c) All other diagnostics issued by the compiler should be conditions
> 	of type NOTICE.

I couldn't find a NOTICE condition in the Condition System document; is
this intended to be a new condition, or where is it defined?

> (3) Require COMPILE-FILE to establish an error handler.  Add a :HANDLER
>     keyword argument to COMPILE-FILE, which is a user condition
>     handler function which is to be used during compilation.  If the
>     user error handler is not supplied or declines to handle a condition,
>     then the compiler's error handler will be invoked. 

To make sure I understand this, does this mean that COMPILE-FILE will look
something like the following?

 (DEFUN COMPILE-FILE (INPUT-FILE &KEY OUTPUT-FILE HANDLER)
   (FLET ((compilers-handler (condition)
 		(issue-message ...) ; should this call WARN?
 		(ABORT)))
     (IF (NULL HANDLER)
 	 (HANDLER-BIND ((ERROR #'compilers-handler))
 	   (internal-compile-file input-file output-file))
       (HANDLER-BIND ((ERROR #'compilers-handler))
 	 (HANDLER-BIND ((ERROR HANDLER))
 	   (internal-compile-file input-file output-file))))))
 
So that if the user wants to enter the debugger he can do:
 
 (compile-file "foo" :handler #'(lambda (c) (invoke-debugger c)))

I wonder if the argument shouldn't be called :ERROR-HANDLER instead of
just :HANDLER in order to be clearer about how it is used?

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

I think that we do want to be able to distinguish compiler-generated
conditions, but it looks like it will depend on the outcome of issue
CLOS-CONDITIONS whether this can be handled by a mixin or whether we would
need conditions COMPILER-ERROR and COMPILER-WARNING.