From: Kent M Pitman
Subject: Re: CLOS: inheriting from a #<build-in-class ***> ?
Date:
Message-ID: <sfwzp7lkt8h.fsf@world.std.com>
Craig Brozefsky <·····@onshore.com> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > Craig Brozefsky <·····@onshore.com> writes:
> >
> > This is true. Though I think the spec doesn't require any particular
> > class to be a built-in class. If you wanted to make an implementation
> > in which all system classes were standard classes, I think you could.
> > The extra term "system class" might appear to be synonymous with built-in
> > class, but it's a system class, not a built-in class, that's forbidden
> > for inclusion in in defclass. INTEGER and friends are defined as
> > system classes, not built-in classes.
>
> Correct, a system class may be a built-in class, but is not required
> too be one. I think you might be transposing the two in your
> statement that it's a system class, not a built-in class that is
> forbidden for inclusion in defclass (and basically everywhere else
> except in a parameter specializer). Actually, and the definition of
> system-class and built-in class in the HS glossary support this, it is
> the built-in classes and not the system classes that are prohibited
> from defclass immediate super lists and elsewhere.
>
> The rest of your paragraph seems to operate with the correct logic so
> I figure your claim otherwise is a typo. The HS makes this level of
> language lawyering so damn easy.
Uh, right. Sigh. It's been a long day.