Issue: CLOS-CONDITIONS (Version 4)

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

Ok, it's `tomorrow' and no one protested so I did a quick overhaul
of this to remove the dead wood.

I did not deliberately change the content of anything, but it would
help if someone would read it top to bottom for continuity just to
be sure I didn't screw it up. I mainly changed the Rationale and
Discussion, and smoothed some wording here and there where things
got elimiated.

If anyone else wants to add commentary pro or con, they should say
so now.

If no one says anything, I'll assume this is ready to ship.
 -kmp

-----
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
	      09-Oct-88, Version 3 by Pitman
	      10-Mar-89, Version 4 by Pitman (remove unsupported options)
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:INTEGRATE):

  1. Define that condition types are CLOS classes.

  2. Define that condition objects are CLOS instances.

  3. Functions such as SIGNAL, which take arguments of class names, are
     permitted to take class objects. Such class objects must still be
     subclasses of CONDITION.

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

  5. Incompatibly change the syntax of a slot in DEFINE-CONDITION
     to be compatible with a DEFCLASS slot specification.

     An implication of this change is that forms like
      (DEFINE-CONDITION FOO (BAR) ((A 1) (B 2)))
     would have to be written
      (DEFINE-CONDITION FOO (BAR)
	((A :INITARG :A :READER FOO-A :INITFORM 1)
	 (B :INITARG :B :READER FOO-B :INITFORM 2)))

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

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

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

Rationale:

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

  Although items 5 and 7 are incompatible with the interim condition
  handling which we've been working with, the overall proposal significantly
  improves compatibility with CLOS.

  This compatibility will make the language seem less fragmented, and
  probably more learnable because there will be fewer paradigms to learn.

  Also, items 5 and 7 in particular are an improvement for reasons
  unrelated to CLOS if only because they get rid of the need for symbol
  concatenation, a process which has been seen to cause problems because
  of the transient nature of the binding of *PACKAGE*.

Examples:

  Slot specifiers...

    A slot specifier of X is still valid but is incompatibly
    changed to mean what CLOS has it mean; no :INITARG or 
    :READER would be supplied.
  
    A slot specifier of (X) is still valid but is incompatibly
    changed to mean what CLOS has it mean; no :INITARG or 
    :READER would be supplied.

    A slot specifier of (X V) would no longer be valid.
    
    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.


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.

  In any case, the total number of uses of DEFINE-CONDITION at this 
  point is probably quite small. Searching for them and repairing
  each by hand is probably not an expensive operation.

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, more learnable language.

Aesthetics:

  Improved.

Discussion:

  Gregor, Pierson, Moon, and Pitman support this proposal.

  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.

  The sense of the cleanup committee was that it was acceptable for
  a vendor to identify a CLOS-free subset of Common Lisp, but that since
  the position of X3J13 seems to be that no resources should be devoted
  to work on subsets, it was inappropriate for us to work out the details
  of that subset ourselves.  Since nothing about this proposal would
  impede such a subset, we took that to be adequate basis for presenting
  this single proposal.

  Moon thinks we might want to add condition types for the errors
  CLOS might signal. Richard Mlynarik thinks we should add a generic
  function, REPORT-CONDITION, which is used for reporting conditions.
  Both of these issues should probably be pursued under separate cover.