From: Peter Seibel
Subject: DEFINE-CONDITION and classes?
Date: 
Message-ID: <m3llu5q8mi.fsf@javamonkey.com>
This is a question for the language lawyers: Is DEFINE-CONDITION
required to create a new class for each condition type it creates? 

Or, to ask it another way, can the names of conditions defined with
DEFINE-CONDITION be used as parameter specializers in a DEFMETHOD
form?

I ask because I noticed the dictionary entry for DEFINE-CONDITION says
it creates a new condition *type* but doesn't say anything about
classes except to say that various parameters are treated the same way
as DEFCLASS treats them.

One reading of that is it would be legal to implement DEFINE-CONDITION
to create a new type with DEFTYPE (perhaps using a SATISFIES type
specifier) and then implement MAKE-CONDITION to create new objects
that are all of the same class but differ in some way that causes them
to be of different types.

Of course the dictionary entries for the various "Condition Types" all
have a "Class Precedence List" so that suggests that conditions types
are supposed to map to a class hierarchy, even if not necessarily one
made up of instances of STANDARD-CLASS.

Any pointers to other parts of the standard I should consider?

-Peter

-- 
Peter Seibel                                      ·····@javamonkey.com

         Lisp is the red pill. -- John Fraser, comp.lang.lisp

From: Peter Seibel
Subject: Re: DEFINE-CONDITION and classes?
Date: 
Message-ID: <m3oez0puyq.fsf@javamonkey.com>
Peter Seibel <·····@javamonkey.com> writes:

> This is a question for the language lawyers: Is DEFINE-CONDITION
> required to create a new class for each condition type it creates? 
> 
> Or, to ask it another way, can the names of conditions defined with
> DEFINE-CONDITION be used as parameter specializers in a DEFMETHOD
> form?
> 
> I ask because I noticed the dictionary entry for DEFINE-CONDITION says
> it creates a new condition *type* but doesn't say anything about
> classes except to say that various parameters are treated the same way
> as DEFCLASS treats them.
> 
> One reading of that is it would be legal to implement DEFINE-CONDITION
> to create a new type with DEFTYPE (perhaps using a SATISFIES type
> specifier) and then implement MAKE-CONDITION to create new objects
> that are all of the same class but differ in some way that causes them
> to be of different types.
> 
> Of course the dictionary entries for the various "Condition Types" all
> have a "Class Precedence List" so that suggests that conditions types
> are supposed to map to a class hierarchy, even if not necessarily one
> made up of instances of STANDARD-CLASS.
> 
> Any pointers to other parts of the standard I should consider?

To partly answer my own question, I found section "4.3.7 Integrating
Types and Classes", in particular Figure 4-8 which specifically states
that all the condition types (as well as a bunch of other types) have
a corresponding class. It doesn't, however, say whether creating a new
condition type with DEFINE-CONDITION necessarily creates a class of
the same name.

-Peter

-- 
Peter Seibel                                      ·····@javamonkey.com

         Lisp is the red pill. -- John Fraser, comp.lang.lisp
From: Steven M. Haflich
Subject: Re: DEFINE-CONDITION and classes?
Date: 
Message-ID: <fP1Za.378$Xa5.241@newssvr27.news.prodigy.com>
Peter Seibel wrote:

> To partly answer my own question, I found section "4.3.7 Integrating
> Types and Classes", in particular Figure 4-8 which specifically states
> that all the condition types (as well as a bunch of other types) have
> a corresponding class. It doesn't, however, say whether creating a new
> condition type with DEFINE-CONDITION necessarily creates a class of
> the same name.

I'm not sure what other convolued meaning you could try to extract from
this requirement.

There is history behind this seemingly pointless muddle and indirection
in the standard.  The condition system was adopted into the language
at the same X3J13 meeting as the object system was adopted.  They were
separate proposals, so obviously, the condition system proposal could
not have been drafted on the assumption the the object system would be
adopted.

The condition system was originally drafted to leave considerable
freedom for implementation using defstruct or whatever (single
inheritance, etc.).  Even after, the committee was cautious about
imposing the requirement that the implementation use standard-object.
It was done eventually, but not until significantly later.

That is why the condition system retains smoe unnatural restrictions
with regard to clos.
From: Peter Seibel
Subject: Re: DEFINE-CONDITION and classes?
Date: 
Message-ID: <m3bruzmdyr.fsf@javamonkey.com>
"Steven M. Haflich" <·················@alum.mit.edu> writes:

> Peter Seibel wrote:
> 
> > To partly answer my own question, I found section "4.3.7 Integrating
> > Types and Classes", in particular Figure 4-8 which specifically states
> > that all the condition types (as well as a bunch of other types) have
> > a corresponding class. It doesn't, however, say whether creating a new
> > condition type with DEFINE-CONDITION necessarily creates a class of
> > the same name.
> 
> I'm not sure what other convolued meaning you could try to extract from
> this requirement.

What I said originally: that DEFINE-CONDITION might only be required
to create a new type not a new class. I'm happy to accept that the
intent of the standard writers was that DEFINE-CONDITION defines a new
class (of, as I understand it, some unspecified metaclass, see below).
And I'm certainly happy to accept that it would be irrational to
implement conditions to not create new classes; i.e. it would be more
trouble than the obvious make-a-new-class implementation and for no
discernable benefit. I was just wondering if there was some part of
the standard that I had missed that explicitly stated that each
DEFINE-CONDITION defines a new class as well as a new type.

> There is history behind this seemingly pointless muddle and
> indirection in the standard. The condition system was adopted into
> the language at the same X3J13 meeting as the object system was
> adopted. They were separate proposals, so obviously, the condition
> system proposal could not have been drafted on the assumption the
> the object system would be adopted.

Yup. I gathered that from several of the Issues included in the CLHS.

> The condition system was originally drafted to leave considerable
> freedom for implementation using defstruct or whatever (single
> inheritance, etc.). Even after, the committee was cautious about
> imposing the requirement that the implementation use
> standard-object. It was done eventually, but not until significantly
> later.

By "it" you mean requiring that conditions be implemented using
standard-object? I wasn't aware that that was ever added to the
standard. And certainly discussion such as this from the SLOT-VALUE
dictionary entry suggest that there is no requirement that conditions
be standard-objects:

  The specific behavior depends on object's metaclass. ... Note in
  particular that the behavior for conditions and structures is not
  specified.

Or do you mean something else by "It was done eventually"?

-Peter

-- 
Peter Seibel                                      ·····@javamonkey.com

         Lisp is the red pill. -- John Fraser, comp.lang.lisp