[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
more on terminology
- To: Handerson @ CMU-CS-C
- Subject: more on terminology
- From: Kent M Pitman <KMP @ MIT-MC>
- Date: 16 October 1984 20:15-EDT
- Cc: cl-error-handling @ SU-AI
- In-reply-to: Msg of Tue 16 Oct 1984 19:28 EDT from Steven <Handerson at CMU-CS-C.ARPA>
Date: Tue, 16 Oct 1984 19:28 EDT
From: Steven <Handerson at CMU-CS-C.ARPA>
Actually, I disagree with the terminology. "Event" is fine.
However, you're presuming that there will be a "condition object"
associated with a particular event, and I think there may be some
other issues we need to get through first. I think condition should
be reserved to mean "an event deemed interesting by CL". That way,
we can talk about whether an event is a condition or not. I also
think less-common word should be used for the things that may
eventually be created - perhaps the phrase "condition object" or
somesuch (we don't need to agree what this is yet). One would then
signal conditions, not events...
Actually, I don't think we disagree on this. This is certainly a
restatement of what I intended to say. If it makes it clearer to
rephrase it this way, I'm happy.
The reason I had proposed eliminating the word "event" was that I
thought it presupposed the existence of objects representing conditions
and I wanted to avoid terminology that forced an object-oriented view of
error handling. Indeed, I think that "condition" is a fine name for what
the LispM documentation calls "events" and I agree that if we ever adopt
an object-oriented view, we should call the objects which represent
conditions "condition objects".
The word "event" is too generic to lock down for any use even so specific
as condition raising, which is another reason I wanted to free it. I don't
think it is fair to assign it technical meaning.