Issue: CLOS-CONDITIONS (Version 1)

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

Any discussion/objections before I pass it along to X3J13? 
I won't be surprised if I've left one or more things out, so
please read not only for errors but also for completeness.
 -kmp

-----
Issue:        CLOS-CONDITIONS
References:   Condition System (Revision 18)
Category:     ADDITION
Edit history: 26-Sep-88, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  The description of the Common Lisp condition system presupposes
  only DEFSTRUCT and not DEFCLASS because it was written when
  CLOS had not been adopted. It is stylistically out of step with
  CLOS in a few places and places some restrictions which are not
  necessary if CLOS can be presupposed.

Proposal (CLOS-CONDITIONS:YES):

  Define that CLOS condition types are CLOS classes.

  Define that CLOS condition objects are CLOS instances.

  Permit multiple parent-types to be named in the list of
  parent types. Define that these parent types are treated the
  same as the superior class list in a CLOS DEFCLASS expression.

  Define that slots in condition objects are normal CLOS slots.
  Note that WITH-SLOTS can be used to provide more convenient
  access to the slots where slot accessors are undesirable.

  Incompatibly change the syntax for a slot in a DEFINE-CONDITION
  form to be the same as for a CLOS slot-specifier. Define that
  these new slot specifiers are handled as they would for DEFCLASS.

  Eliminate the :CONC-NAME option to DEFINE-CONDITION.

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

Examples:

  Slot specifiers...

    A slot specifier such as X is still valid.
  
    A slot specifier such as (X) is still valid.
  
    A slot specifier such as (X V) is no longer valid. Instead,
    one must write (X :INITFORM X).
    
    In addition, other slot specifiers such as
     (X :INITARG :EX :TYPE FIXNUM)
    are permitted.

 Conc names ...

   (DEFINE-CONDITION FOOBAR (FOO BAR) (X Y) (:CONC-NAME FUBAR))
   would be rewritten
   (DEFINE-CONDITION FOOBAR (FOO BAR)
     ((X :ACCESSOR FUBAR-X)
      (Y :ACCESSOR FUBAR-Y)))

 Report methods ...

   (DEFINE-CONDITION OOPS (ERROR) ())
   (DEFMETHOD PRINT-OBJECT ((X OOPS) STREAM)
     (IF *PRINT-ESCAPE* 
	 (CALL-NEXT-METHOD)
	 (FORMAT STREAM "Oops! Something went wrong.")))
   (ERROR 'OOPS)
   >>Error: Oops! Something went wrong.

Rationale:

  These changes are consistent with the intent of the recent
  X3J13 endorsement of CLOS and the Common Lisp Condition System.

Current Practice:

  Some implementations supporting CLOS probably already do this.

Cost to Implementors:

  If you really have CLOS, this is very straightforward.

Cost to Users:

  Small, but tractable.

  The main potential problems are:

   - :CONC-NAME. There is nothing that keeps an implementation from
     continuing to support :CONC-NAME for a short while until old code
     has been upgraded.

   - The incompatible change to slot syntax. Again, it is possible to
     unambiguously recognize a 2-list as old-style syntax and an
     implementation can provide interim compatibility support during
     a transition period.

  Even if implementations did not provide the recommended compatibility
  support, users could trivially shadow DEFINE-CONDITION and provide the
  support themselves, expanding into the native DEFINE-CONDITION in the
  proper syntax.

Cost of Non-Adoption:

  Conditions will seem harder to manipulate than other user-defined types.

  People will wonder if CLOS is really something we're committed to.

Benefits:

  A more regular language.

Aesthetics:

  Anything that makes the language more regular improves the aesthetics.

Discussion:

  People seem to disagree about the status that CLOS might occupy
  in the upcoming standard. In spite of a vote of support, they seem
  to think it might be optional in some way. Passing this proposal
  establishes a clear precedent for the full integration of CLOS into
  the emerging language.

  Pitman supports this change.