Issue DEFINE-CONDITION-SYNTAX Writeup

Issue:		DEFINE-CONDITION-SYNTAX

Forum:		Cleanup

References:	Condition System, Version 18

		CLOS Specification, 88-002R

		Issue CLOS-CONDITIONS

		Issue CONDITION-ACCESSORS-SETFABLE

Category:	CHANGE/CLARIFICATION

Edit History:	Version 1, 1/3/90 by Kim A. Barrett


Problem Description:

  Issue CLOS-CONDITIONS incompatibly changed the slot specification syntax

  for DEFINE-CONDITION to match the slot specification syntax for DEFCLASS.

  This leaves us with two defining macros whose general forms are very

  similar but which have small idiosyncratic differences.


Notes on voting:

 Vote for just 1 of MORE-LIKE-DEFCLASS, INCOMPATIBLY-MORE-LIKE-DEFCLASS, or

   MORE-LIKE-DEFINE-CONDITION.

 In addition, vote yes or no to EMPHASIZE-READ-ONLY.


Proposal (DEFINE-CONDITION-SYNTAX:MORE-LIKE-DEFCLASS):

  Define the syntax for DEFINE-CONDITION to be


    DEFINE-CONDITION name ({supertype}*) [({slot}*) {option}*]


    option ::= (:DEFAULT-INITARGS initarg-list) |

	       (:DOCUMENTATION string) |

	       (:REPORT exp)


  The :default-initarg option is defined in the same way as for DEFCLASS.  The

  :documentation and :report options are unchanged.


  If no supertypes are specified, then the condition being defined inherits

  directly from CONDITION.


Proposal (DEFINE-CONDITION-SYNTAX:INCOMPATIBLY-MORE-LIKE-DEFCLASS):

  As DEFINE-CONDITION-SYNTAX:MORE-LIKE-DEFCLASS, but make the slot

  specification list required.


Proposal (DEFINE-CONDITION-SYNTAX:MORE-LIKE-DEFINE-CONDITION):

  As DEFINE-CONDITION-SYNTAX:MORE-LIKE-DEFCLASS, but change the syntax of

  DEFCLASS so that the slot specification list is optional.


Proposal (DEFINE-CONDITION-SYNTAX:EMPHASIZE-READ-ONLY)

  As either of the above proposals, but remove the :WRITER and :ACCESSOR

  slot options.


Rational:

  This provides the added functionality provided by :DEFAULT-INITARGS, and

  the convenience of not having to explicitly write CONDITION as the only

  super for some conditions.


  INCOMPATIBLY-MORE-LIKE-DEFCLASS makes the basic syntax identical, but at

  the cost of an incompatible change, since the list of slot specifications

  will no longer be optional.


  EMPHASIZE-READ-ONLY emphasizes the point that it is an error to attempt

  to assign a condition's slots using SETF.  Condition objects are supposed

  to be at least conceptually read-only.


Current Practice:

  IIM supports the :DEFAULT-INITARGS option.  They may support the behavior

  specified for an empty supertype list (if they don't, then they still

  require at least one supertype).


Cost to Implementors:

  Supporting an empty supertype list in the specified way is probably fairly

  trivial.  For an implementation of conditions which is not based on an

  implementation of CLOS, adding the support for :default-initargs might not

  be trivial.


Cost to Users:

  MORE-LIKE-DEFCLASS is upwardly compatible for the status quo.


  The other two proposals will probably require some programs to be modified.

  As an interim solution implementations could support MORE-LIKE-DEFCLASS and

  issue warnings for cases which were incompatible with the other two

  proposals.


Benefits:

  Programmers would need to remember fewer idiosyncratic differences in the

  syntax of two very similar and important macros.


Discussion:

  Barrett supports MORE-LIKE-DEFINE-CONDITION.  He thinks that 

  EMPHASIZE-READ-ONLY would be a good idea if there isn't too much concern

  about the incompatibility issues.


  Pitman supports MORE-LIKE-DEFCLASS but mostly because the CLOS crew are

  a stubborn bunch and it seems more likely that we can bend the rest of the

  spec to be like their polished piece of prose than vice versa.  

  (i.e., MORE-LIKE-DEFINE-CONDITION is technically just as good to him.)

  Pitman also supports EMPHASIZE-READ-ONLY.


-----

Additional comments in response to write-up:


Moon (11 Jan 90):


  This issue raises good points that I think were overlooked in past

  discussions of unifying Conditions and CLOS.

  

  I am neutral among MORE-LIKE-DEFCLASS, INCOMPATIBLY-MORE-LIKE-DEFCLASS,

  or MORE-LIKE-DEFINE-CONDITION.  The incompatibilities here (either making

  the slot-specifier list optional where it's mandatory or mandatory where

  it is optional) are of little concern since the adjustment is tiny.  Any

  one of these would be a significant improvement over the status quo.

  

  I am definitely in favor of EMPHASIZE-READ-ONLY and not impressed by the

  compatibility arguments.  An existing program that is incompatible with

  this either actually modifies condition objects, in which case it can't

  work, or it just accidentally says :ACCESSOR but only uses the reader,

  in which case it is trivial to fix.