Issue: CLOS-CONDITIONS (Version 2)

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

Changes per Moon's suggestions.
 - I fixed some cited typos.
 - I changed the way slot descriptions are handled.
   This has the most chance of being controversial.
 - I extended SIGNAL and friends to take class objects.

If anyone has any objections to the changes I've made or
unrelated objections to raise, they should do so ASAP.

-----
Issue:        CLOS-CONDITIONS
References:   Condition System (Revision 18)
Category:     ADDITION
Edit history: 26-Sep-88, Version 1 by Pitman
	      06-Oct-88, Version 2 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 condition types are CLOS classes.

  Define that 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.

  Extend the syntax for a slot in a DEFINE-CONDITION as follows...

   - If a symbol is used, DEFINE-CONDITION will by special case
     treat this as if (symbol :INITARG keyword :READER reader-name)
     were specified instead, where KEYWORD is generated by
	(INTERN (SYMBOL-NAME symbol) (FIND-PACKAGE "KEYWORD"))
     and reader-name is generated by
 	(INTERN (FORMAT NIL "~A-~A" condition-type symbol))
     for CONDITION-TYPE being the condition type being defined.

   - A length 1 list, (symbol), is treated the same as providing
     the symbol itself.

   - If a length 2 list, (symbol value) is provided, it is treated
     as (symbol :INITARG keyword :READER reader-name :INITFORM value),
     with KEYWORD and READER-NAME being computed as above.

   - If a list of length greater than 2 is used, it is treated
     the same as a CLOS slot-specifier. In that case, the :INITARG
     and :READER options must be explicitly specified if desired.

  Functions such as SIGNAL, which take arguments of class names,
  are permitted to take class objects.

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

Examples:

  Slot specifiers...

    A slot specifier of X in condition type FOO is still valid
    and means the same as (X :INITARG :X :READER FOO-X).
  
    A slot specifier of X in condition type FOO is still valid
    and means the same as (X :INITARG :X :READER FOO-X).
  
    A slot specifier of (X V) in condition type FOO is still
    valid and means the same as 
     (X :INITARG :X :READER FOO-X :INITFORM V).
    
    In addition, other slot specifiers such as
     (X :INITARG :EX :TYPE FIXNUM)
    are permitted as in DEFCLASS.

 Conc names ...

   (DEFINE-CONDITION FOOBAR (FOO BAR) (X Y) (:CONC-NAME FUBAR))
   would be rewritten
   (DEFINE-CONDITION FOOBAR (FOO BAR)
     ((X :INITARG :X :READER FUBAR-X)
      (Y :INITARG :Y :READER 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.

  The shorthand notations for DEFINE-CONDITION's slots spec
  are justified since the the way in which condition slots are
  used is much more highly constrained than for arbitrary classes.
  This means we can predict what will be the common case and make
  it far more syntactically convenient than it might otherwise be.

  Although flushing :CONC-NAME is an incompatible change, nothing
  forbids an implementation from supporting it as an extension
  during a transition period.

Current Practice:

  Some implementations supporting CLOS probably already do this,
  or something very similar.

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.

  Moon suggests that we might want to add condition types for the errors
  CLOS might signal. It isn't obvious (to Pitman, at least) that this 
  change is as straightforward as it looks, though, so it will have to
  come up under separate cover.