Re: Draft Issue: CLOS-CONDITIONS (Version 3)

[masinter.pa@Xerox.COM]

I thought there might be a way to word this proposal in a way that would
make the error/signal system *compatible* with CLOS but not to actually
make it require the low-level implementation to *use* CLOS if it didn't
want to. Many vendors are only now working on integrating CLOS into their
environment. A lot of the concern is for "staging" the introduction of CLOS
and the condition system. This is also a concern for those with existing
implementations where they might want to load in the CLOS support late in
the system-building process, and yet use the condition system early in that
process. While this is an implementation detail, the implementation
ramifications of your proposal need to be spelled out.

-

Most of the changes can be couched the following way:

"Define that the condition types are CLOS classes" => "the functions
defined in CLOS that work on classes will work on condition types."

"Define that condition objects are CLOS instances" => ""

(since all objects in Common Lisp are CLOS instances, right?)

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

just define what that means and note that it is the same as the operation
of superior class lists in CLOS.

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

=> ""

This is a straightforward implication of making condition types into
classes.

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

This is fine.

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

Why?

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

This is fine, although you can say it a different way:

the PRINT-OBJECT generic function in CLOS can be used ...