Error Proposal #5 questions

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

    Date: Thu, 3 Apr 86 01:14 EST
    From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
    Subject: Error Proposal #5 questions
    To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>

	Date: Tue, 1 Apr 86 02:59 EST
	From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>

	    4. In WARN, what is the "text of the warning" if a condition was passed
	    instead of a format string? (I assume that the way warnings are printed
	    is something like (FORMAT *ERROR-OUTPUT* "Warning: ~A." condition))

	Yes, that's right. If a condition is passed, its report function is used. In 
	principle, you can WARN things that are not based on WARNING, by the way. I
	dunno if anyone would do that, but it's legal in my proposal. I saw no reason
	to forbid it, so I didn't.)

    Some implementations may define additional protocols on warnings, relating
    to saving them in a database, delaying certain warnings so they can be
    checked later (i.e. undefined-function, etc). WARNING may provide the
    basis for this protocol. I haven't had a chance to read the proposal; how does 
    WARN differ from SIGNAL?

I had some ideas about this but they're not made clear in the proposal. My general
intuition is that it's good to allow such extensions but bad to arrange for them
by building them into the WARNING condition, especially in systems which don't allow
non-hierarchical inheritance, which this proposal doesn't try to presuppose. I believe
we should try to lock down a little more detail on this. 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.

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.

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.

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

Does anyone else have thoughts on how we should pin this down?