[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]


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.


[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996-2005, LispWorks Ltd. All rights reserved.