[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: CLOS-CONDITIONS (Version 4)
- To: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
- Subject: Issue: CLOS-CONDITIONS (Version 4)
- From: Richard Mlynarik <Mly@AI.AI.MIT.EDU>
- Date: Mon, 13 Mar 89 12:35 EST
- In-reply-to: <890310140701.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Fri, 10 Mar 89 14:07 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Proposal (CLOS-CONDITIONS:INTEGRATE):
1. Define that condition types are CLOS classes.
2. Define that condition objects are CLOS instances.
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.
This isn't any sort of clarification. The actual clarification required
-- which has been requested several times, and not just by myself -- is
what the *METACLASS* of condition types is.
Condition types may be "CLOS classes" without being STANDARD-CLASSes
Condition objects may be "CLOS instances" without being STANDARD-OBJECTs.
Just what are "normal CLOS slots"? As I see it, the "normalcy" or
otherwise of slots is determined by the metaclass.
My opinion for some time has been that condition types should not be
STANDARD-CLASSes but instead something like READ-ONLY-CLASS.
Conceptually, It Is An Error to modify the slots of condition objects,
which are supposed to be immutable descriptions of part of the state of
a computation. Implementationally,
(setf (slot-value <condition-object> <slot-name>) <new-value>) should
signal an error.
(I also think that conditions in particular have a strong need for
something like :REQUIRED-INIT-KEYWORDS, but that's another story.)
Even if you decide to make condition classes' metaclass STANDARD-CLASS,
the point is that you need to state this, so that users may define
condition classes and mixins using DEFCLASS.
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.
Since, as you know, I largely regard work on the Common Lisp condition
system as a waste of my time, this won't happen until somebody else
realises that it is needed.