Re: issue COMPILER-DIAGNOSTICS, version 2

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Thu, 20 Oct 88 14:59:14 MDT
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    ... I'm not sure that we want to -require- the compiler's error
    handler to turn errors into warnings, but certainly they should be
    -allowed- to do so.  And, I still think it's important for a user
    error handler to be able to distinguish between serious compilation
    problems and mere kibbitzing.

It's important to note that we're not forcing a compiler to behave a
specific way, only forcing COMPILE-FILE. Suppose an implementation's
primitive file-compiler is called COMPILER:COMPILE-FILE and suppose
that function lets errors show through. Nothing keeps the implementors
 from building LISP:COMPILE-FILE atop that function in a way that is
compatible. eg,

 (DEFUN COMPILE-FILE (FILE &REST ARGUMENTS &KEY HANDLER)
   (FLET ((DO-IT () 
	    (APPLY #'COMPILER:COMPILE-FILE FILE :ALLOW-OTHER-KEYS T ARGUMENTS)))
     (HANDLER-BIND ((ERROR #'ABORT-INNERMOST-COMPILATION-HANDLER))
       (IF HANDLER
	   (HANDLER-BIND ((ERROR HANDLER)) (DO-IT))
	   (DO-IT)))))

    ...  Would we also want to add a *COMPILE-VERBOSE* variable?  Is
    there any reason why this shouldn't be split off as a separate issue?
    (One could argue that what the compiler prints out during its normal
    operation has nothing at all to do with what it does with errors.)

Since this has nothing to do with conditions and will presumably raise a
completely different set of issues, I think separating it is a very good idea.