According to the ANSI CL standard,
(BUILT-IN-CLASS page) "Attempting to use defclass to define
subclasses of a built-in class signals an error of type error."
The subclass relation is defined by (section 4.3.1):
A class C1 is a direct superclass of a class C2 if C2 explicitly
designates C1 as a superclass in its definition. In this case C2
is a direct subclass of C1. A class Cn is a superclass of a class
C1 if there exists a series of classes C2,...,Cn-1 such that Ci+1
is a direct superclass of Ci for 1 <=i<n. In this case, C1 is a
subclass of Cn.
Finally,
The class named t has no superclasses. It is a superclass of every
class except itself.
From this, I conclude that if T is a built-in class, every evaluation
of a defclass form must signal a type error. I don't imagine this is
what was intended.
Paul
From: Tim Bradshaw
Subject: Re: Creating subclasses of builtin types
Date:
Message-ID: <ey3of4uviau.fsf@cley.com>
* Paul F Dietz wrote:
> According to the ANSI CL standard,
> (BUILT-IN-CLASS page) "Attempting to use defclass to define
> subclasses of a built-in class signals an error of type error."
I presume it should say `direct subclasses'. I guess that is a bug.
--tim
From: Timothy Moore
Subject: Re: Creating subclasses of builtin types
Date:
Message-ID: <b3roab$dur$0@216.39.145.192>
"Paul F. Dietz" <·····@dls.net> writes:
> According to the ANSI CL standard,
>
> (BUILT-IN-CLASS page) "Attempting to use defclass to define
> subclasses of a built-in class signals an error of type error."
>
> The subclass relation is defined by (section 4.3.1):
>
> A class C1 is a direct superclass of a class C2 if C2 explicitly
> designates C1 as a superclass in its definition. In this case C2
> is a direct subclass of C1. A class Cn is a superclass of a class
> C1 if there exists a series of classes C2,...,Cn-1 such that Ci+1
> is a direct superclass of Ci for 1 <=i<n. In this case, C1 is a
> subclass of Cn.
>
> Finally,
>
> The class named t has no superclasses. It is a superclass of every
> class except itself.
>
> From this, I conclude that if T is a built-in class, every evaluation
> of a defclass form must signal a type error. I don't imagine this is
> what was intended.
But built-in-class is a subclass of T! T is not a subclass of
built-in-class, so T "is not a built-in class." Assuming that
"built-in class" means "a class with built-in-class in its class
precedence list."
Tim
Timothy Moore wrote:
> But built-in-class is a subclass of T! T is not a subclass of
> built-in-class, so T "is not a built-in class." Assuming that
> "built-in class" means "a class with built-in-class in its class
> precedence list."
You have confused 'is an element of' with 'is a subtype of'.
The class T can be an element of built-in-class without
being a subtype of built-in-class.
Paul
From: Timothy Moore
Subject: Re: Creating subclasses of builtin types
Date:
Message-ID: <b3s1a1$b5p$0@216.39.145.192>
"Paul F. Dietz" <·····@dls.net> writes:
> Timothy Moore wrote:
>
> > But built-in-class is a subclass of T! T is not a subclass of
> > built-in-class, so T "is not a built-in class." Assuming that
> > "built-in class" means "a class with built-in-class in its class
> > precedence list."
>
> You have confused 'is an element of' with 'is a subtype of'.
>
> The class T can be an element of built-in-class without
> being a subtype of built-in-class.
>
> Paul
I have no idea where you get "is an element of" from. You previously said:
> From this, I conclude that if T is a built-in class, every evaluation
>of a defclass form must signal a type error. I don't imagine this is
>what was intended.
Perhaps I'm confusing "is" with "is an element of", but when talking
about types and classes "is" means "is a subtype of" or "is a
subclass of" to me.
Tim
Timothy Moore wrote:
> Perhaps I'm confusing "is" with "is an element of", but when talking
> about types and classes "is" means "is a subtype of" or "is a
> subclass of" to me.
No, 'is' means membership in a class, which is quite distinct from
the subclass relationship.
The class named T is a member of its metaclass, but not a subclass
of its metaclass.
Paul
From: Timothy Moore
Subject: Re: Creating subclasses of builtin types
Date:
Message-ID: <b3s3sj$b5p$1@216.39.145.192>
"Paul F. Dietz" <·····@dls.net> writes:
> Timothy Moore wrote:
>
> > Perhaps I'm confusing "is" with "is an element of", but when talking
> > about types and classes "is" means "is a subtype of" or "is a
> > subclass of" to me.
>
> No, 'is' means membership in a class, which is quite distinct from
> the subclass relationship.
>
> The class named T is a member of its metaclass, but not a subclass
> of its metaclass.
>
> Paul
Well yes, but how/why are you bringing metaclasses into this? The
language you quoted from the spec says nothing about metaclasses.
Tim
Timothy Moore wrote:
> Well yes, but how/why are you bringing metaclasses into this?.
Built-in-class is a metaclass.
Paul
From: Timothy Moore
Subject: Re: Creating subclasses of builtin types
Date:
Message-ID: <b3scq4$7f9$0@216.39.145.192>
"Paul F. Dietz" <·····@dls.net> writes:
> Timothy Moore wrote:
>
> > Well yes, but how/why are you bringing metaclasses into this?.
>
> Built-in-class is a metaclass.
>
> Paul
Ah, I understand now. I should have read a bit more carefully, though
I suppose that Kent's point about knowing when something is obviously
wrong applies. I had a feeling that I shouldn't get in an argument
about the Spec with Paul, but I unfortunately ignored it :)
Tim
Timothy Moore <·····@bricoworks.com> writes:
> "Paul F. Dietz" <·····@dls.net> writes:
>
> > Timothy Moore wrote:
> >
> > > But built-in-class is a subclass of T! T is not a subclass of
> > > built-in-class, so T "is not a built-in class." Assuming that
> > > "built-in class" means "a class with built-in-class in its class
> > > precedence list."
> >
> > You have confused 'is an element of' with 'is a subtype of'.
> >
> > The class T can be an element of built-in-class without
> > being a subtype of built-in-class.
> >
> > Paul
>
> I have no idea where you get "is an element of" from. You previously said:
>
> > From this, I conclude that if T is a built-in class, every evaluation
> >of a defclass form must signal a type error. I don't imagine this is
> >what was intended.
>
> Perhaps I'm confusing "is" with "is an element of", but when talking
> about types and classes "is" means "is a subtype of" or "is a
> subclass of" to me.
Well, T is described as a "system class" whose class precedence list contains
only itself. The decision to list it as a system class was probably mine,
not the CLOS committee's, and was probably an error because it is true that
the glossary says:
system class n. a class that may be of type built-in-class in a
conforming implementation and hence cannot be inherited by
classes defined by conforming programs.
and I suppose a strict reading of this says that you can't inherit T.
However, I think the real error is that the "hence..." part shouldn't have
been there because it's not so much definitional as a conclusion from the
first part of the sentence. I think the whole point about it being "maybe"
of type built-in-class is that implementations can do that if the other
needs of the class are satisfied that way; it seems clear to me that
T cannot really be built-in-class, and so still "may be of type built-in-class,
but happens not to be in all cases". Heh. Well, that's how I'd have thought
about it, anyway...
The CLOS committee thought very hard about the details of the CLOS spec,
and I changed hardly a word of what they gave me (other than to normalize
terminology and format).
Also, we've always used the rule that in the case of an out-and-out error where
no implementation actually believes the written wording, one just shouldn't
fret. And I think that's the case here. Same as the problem with PROG2's
return value... (more embarrassed laughter) (well, i KNEW something like that
would certainly come up the moment we froze...)
Incidentally, "subclass of" always implies "subtype of", since classes
are types. (Subtype doesn't necessarily imply subclass of, since
types don't have to involve classes.)
The term "is an element of" means "member of type".
The term "is a subtype of" means "subtype of type".
Paul F. Dietz <·····@dls.net> wrote:
> According to the ANSI CL standard,
>
> (BUILT-IN-CLASS page) "Attempting to use defclass to define
> subclasses of a built-in class signals an error of type error."
>
> The subclass relation is defined by (section 4.3.1):
>
> A class C1 is a direct superclass of a class C2 if C2 explicitly
> designates C1 as a superclass in its definition. In this case C2
> is a direct subclass of C1. A class Cn is a superclass of a class
> C1 if there exists a series of classes C2,...,Cn-1 such that Ci+1
> is a direct superclass of Ci for 1 <=i<n. In this case, C1 is a
> subclass of Cn.
>
> Finally,
>
> The class named t has no superclasses. It is a superclass of every
> class except itself.
>
> From this, I conclude that if T is a built-in class, every evaluation
> of a defclass form must signal a type error. I don't imagine this is
> what was intended.
I think the consequence of this is that T should not be a built-in class.
But I suppose there are other ways of resolving this conflict, too.
My remarks above aren't the only way to resolve this--just my personal
preference. It seems self-consistent to also say that built-in-class can
be subclassed only for class T. But there are enough other weird things
about class T that just assuming it has some magical other metaclass
seems more straightforward.
Note that built-in-class is:
A built-in class is a class whose instances have restricted
capabilities or special representations.
NOT
A built-in class is THE class whose ...
That is, there's no reason to suppose that all system classes that are not
standard class are built-in-class.
This "implementational vaguery" is the precise reason for "system class"
to exist in the first place.
My apologies for whatever part I may have had, as editor, in creating
any of the above confusion originally, btw. Live and learn.