Issue: CLOS-CONDITIONS (Version 1)

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

    Date: Tue, 27 Sep 88 18:05 EDT
    From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
    ....

      Define that CLOS condition types are CLOS classes.

      Define that CLOS condition objects are CLOS instances.

Is the first occurrence of CLOS on each line a typo?  If not,
I don't know what a "CLOS condition" is.

      Define that condition reporting is mediated through the
      PRINT-OBJECT method for the condition type (class) in question,
      with *PRINT-ESCAPE* always being NIL. Specifying 
      (:REPORT fn) in the definition of a condition type C is
      equivalent to doing
       (DEFMETHOD PRINT-OBJECT ((X c) STREAM)
	 (IF *PRINT-ESCAPE* (CALL-NEXT-METHOD) (fn X C)))

(fn X C) should be (fn X STREAM).  Also, use upper or lower
case C consistently.

Clarify that DEFINE-CONDITION automatically adds :INITARG
and :READER slot-options.  Specify what happens if the user
writes these slot-options herself; do they override the
default ones, or do both sets of slot-options apply?

 * Daniels still thinks there should be a way to access and modify report
   functions for conditions without going through DEFINE-CONDITION again.
   [This has been blocked waiting for CLOS to settle down.]

I'm not sure whether you regard this issue as settled now, or
need to do something more.

Some functions like SIGNAL take an argument that can be among
other things a condition-type.  Is it valid to use a class object
as a condition type, in addition to a class name being valid?

CLOS itself signals some new errors and standardized condition
names for those signals could be added.

There are also a lot of editorial changes to be made to the
rev-18 document, to reflect the existence of CLOS.  They're
pretty obvious, like take out all the complaints that there
is no standardized object system.