Issue CONDITION-SLOTS Writeup

Issue:         CONDITION-SLOTS


References:    Condition System, version 18

               Issue CLOS-CONDITIONS

               Issue PACKAGE-CLUTTER

               ANSI CL draft pp.5-4, 5-5


Category:      CLARIFICATION


Edit history:  3-Jan-90, Version 1 by Barrett

               30-Apr-90, Version 2 by Moon (rewrite, just one proposal,

                 extend to cover all specified objects that have slots)


Problem description:


  Pages 5-4 and 5-5 of the ANSI CL draft specification from last fall refer

  to slots of specified conditions.  However these slots were not put into

  the specification in a consistent way.


  CLOS-CONDITIONS:INTEGRATE, which was adopted by X3J13, changed condition

  slots to be the same as CLOS slots, but did not say that the specified

  conditions have any specified slots.  However, some people have taken it

  to mean that the condition classes defined by the standard all contain

  slots whose names are external symbols in the CL package which are

  STRING= to the specified initargs for creating conditions.  The ANSI CL

  draft specification was edited in some places as if this were true.


  Revision 18 of the conditions document, which was adopted by X3J13,

  refers to initialization arguments and accessors, but carefully avoids

  naming the slots themselves.  The philosophy of that document was that

  slots are only defined for programmer defined conditions, and that the

  only sanctioned interface for the standard condition classes is through

  the use of the defined accessor functions.


  A related, more general issue that PACKAGE-CLUTTER:REDUCE failed to

  address is whether there are naming restrictions on

  implementation-dependent slots of specified classes.


  This is Symbolics issue #8 and Loosemore issue #15 of 27 Feb 90.


Proposal (CONDITION-SLOTS:HIDDEN):


  1. Clarify that no specified condition classes have any specified slots.

  The implementation of the required information storage by the specified

  condition classes is implementation-dependent.  We need to be clear that

  specified conditions are not required to have any particular slots with

  any particular names.  They -are- required to be the type of object that

  is able to have slots.  User-defined conditions -are- required to have

  slots with the names mentioned in the DEFINE-CONDITION form.


  2. Table 5-1 in the ANSI CL draft specification should not contain slot

  names, because they will not necessarily be accessible via WITH-SLOTS in

  the way people might infer.  Instead, the table should mention initargs

  and accessors.  For example, :FORMAT-STRING and

  SIMPLE-CONDITION-FORMAT-STRING -- but not the symbol FORMAT-STRING.

          

  3. Define that it is unspecified whether slots are involved in the

  operation of specified functions on instances of specified classes,

  except when slots are explicitly specified by the standard.


  4. Define that if in a particular implementation a specified class has

  slots that are not specified by the standard, the names of these slots

  must not be external symbols of packages defined in the standard nor

  otherwise accessible in the USER package.


Rationale:


  Allowing the information storage to be implementation-dependent is

  essential to compatibility with existing systems, which may not represent

  this information in the "obvious" way.


  Specifying slots for the condition classes would require putting the slot

  names into the COMMON-LISP package, adding many symbols.


  Part 4 of the proposal repairs an omission in PACKAGE-CLUTTER:REDUCE.  It

  is necessary if users are to be able to define a subclass of a condition

  class (which is necessary whenever users define their own conditions) and

  give slots to their class without potentially interfering with

  implementation-defined slots.


Current practice:


  Parts 1 through 3 are likely to be consistent with all existing

  implementations.  Part 4 is not known to be specifically violated by any

  implementation, but it might well be violated by accident.  I have not

  tested any implementations specifically.


Cost to Implementors:


  Easy, all they have to do is keep slot names out of user visible packages.


Cost to Users:


  Easy, all they have to do is use the specified accessors rather than

  SLOT-VALUE or WITH-SLOTS to access information in conditions.


Cost of non-adoption:


  Substantially increased size of the COMMON-LISP package and considerable

  extra work on the ANSI CL specification to document all the slots.

  Porting problems for any code that defines its own condition types

  because of slot name collisions.


Performance impact:


  None of any consequence.  SLOT-VALUE might be faster than calling an

  accessor in some implementations (although in most implementations it is

  slower, when not called from a method), but access to a slot of a

  condition never occurs in important inner loops.


Benefits:


  Conditions will be specified as originally intended.


Esthetics:


  Abstraction is better than mandating one particular implementation

  of information storage.


Discussion:


  None.