Error Proposal #5: Warnings

[David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>]

    Date: Fri, 4 Apr 86 13:17 EST
    From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
    Here are a couple of possible ways to refine the proposal ...

     * We could say that WARNING has a default handler which does the typeout 
       and that the WARN function is basically like SIGNAL except that the 
       default type of condition signalled is SIMPLE-WARNING instead of
       SIMPLE-CONDITION. This has the bad problem that if you do something
       like (WARN 'STREAM-ERROR) you enter the debugger instead of getting a
       warning typed out since the default handler for STREAM-ERROR goes into
       the debugger.

     * We could say that WARNING doesn't have any special default handler 
       (just gets used for type inclusion so that people can handle it). In that
       case, the implementation of WARN might look like:
	 (PROCEED-CASE (PROGN (SIGNAL ...)
			      (FORMAT *ERROR-OUTPUT* "Warning: ~A." condition))
	   (SKIP-WARNING ()))
       would be best. That way, WARN will SIGNAL and upon return (if there is
       a return) will always do a warning even for non-WARNING-based conditions.
       unless some handler specifically specifies that the warning should be skipped.
       This has the same problem that you enter the debugger on 
       (WARN 'UNBOUND-VARIABLE ...) but at least you have the knowledge that if
       that entry to the debugger had returned (which it can't unless you use 
       special debugger commands that would be beyond the scope of this proposal)
       it -would have- typed a warning.

     * Another, completely different, way we could go at it would be to say that WARN
       does roughly:
   
	(PROCEED-CASE (LET ((C (MAKE-CONDITION ...hair based on arg types...)))
			(SIGNAL 'WARNING :ENCAPSULATED-CONDITION C)
			(FORMAT *ERROR-OUTPUT* "Warning: ~A." C))
	  (SKIP-WARNING ()))
   
       so that the given condition is not actually signalled but a known type is. 
       In that case, we could flush SIMPLE-WARNING since the encapsulated condition
       could just be type SIMPLE-CONDITION if no condition type was specified.

    Of course, it could just avoid the problem of non-WARNING-based conditions by
    erring if the given condition type was not a subtype of WARNING.

I think this last suggestion is by far the most sensible.  Why should we cater to
people who want to pass bogus arguments to the WARN function?  Just say that it is
an error to pass a condition or a condition-type that is not a subtype of WARNING.

    I think the important things to achieve with WARN are:

     * In general, it should type a warning on the console.

     * It should not be easy to trick it into -not- typing a warning (eg, by giving
       it a non-warning condition type).

     * It should be possible to "notice" a warning. eg,
	(CONDITION-BIND ((WARNING #'(LAMBDA (CONDITION)
				      (PUSH CONDITION *LIST-OF-WARNINGS*))))
	  ...)

     * It should be possible to muffle a warning. eg,
	(CONDITION-BIND ((WARNING #'(LAMBDA (CONDITION)
				      (IF (... some test ...) (SKIP-WARNING CONDITION)))))
	  ...)
       Note that SKIP-WARNING was just made up for the purpose of this message. 
       A better name would be a good idea.

     * It should be possible to reword a warning. eg,
	(CONDITION-BIND ((WARNING #'(LAMBDA (CONDITION)
				      (WHEN (... some test ...)
					(... alternate I/O or call to WARN ...)
					(SKIP-WARNING CONDITION)))))
	  ...)

All of these seem to work straightforwardly with your last suggestion,
but each of your three asterisked suggestions breaks one or more of
these goals.