From: Paul F. Dietz
Subject: ANSI CL question: are standard CL class names proper names?
Date:
Message-ID: <3DE7F1C7.4030707@dls.net>
There are a number of classes defined in the ANSI CL standard.
My question is: for each such symbol x in the CL package,
is this required to be true:
(eq x (class-name (find-class x))) ?
If so, where in the standard does it say that?
Paul
"Paul F. Dietz" <·····@dls.net> writes:
> There are a number of classes defined in the ANSI CL standard.
>
> My question is: for each such symbol x in the CL package,
> is this required to be true:
>
> (eq x (class-name (find-class x))) ?
>
> If so, where in the standard does it say that?
I'm pretty sure the standard very carefully does not say this.
I think it's important to interdialect compatibility that you don't
depend on this.
Of curiosity, why do you need it?
From: Paul F. Dietz
Subject: Re: ANSI CL question: are standard CL class names proper names?
Date:
Message-ID: <3DE840C4.4000908@dls.net>
Kent M Pitman wrote:
>>My question is: for each such symbol x in the CL package,
>>is this required to be true:
>>
>> (eq x (class-name (find-class x))) ?
>>
>>If so, where in the standard does it say that?
>
>
> I'm pretty sure the standard very carefully does not say this.
>
> I think it's important to interdialect compatibility that you don't
> depend on this.
>
> Of curiosity, why do you need it?
I'm writing a set of ANSI CL compliance tests.
BTW, I did subsequently find this in section 4.3.7 (which, for some
reason, is tucked under 4.3.6 in the Hyperspec):
Many but not all of the predefined type specifiers have a corresponding
class with the same proper name as the type. These type specifiers are
listed in Figure 4-8.
Table 4-8 contains:
arithmetic-error generic-function simple-error
array hash-table simple-type-error
bit-vector integer simple-warning
broadcast-stream list standard-class
built-in-class logical-pathname standard-generic-function
cell-error method standard-method
character method-combination standard-object
class null storage-condition
complex number stream
concatenated-stream package stream-error
condition package-error string
cons parse-error string-stream
control-error pathname structure-class
division-by-zero print-not-readable structure-object
echo-stream program-error style-warning
end-of-file random-state symbol
error ratio synonym-stream
file-error rational t
file-stream reader-error two-way-stream
float readtable type-error
floating-point-inexact real unbound-slot
floating-point-invalid-operation restart unbound-variable
floating-point-overflow sequence undefined-function
floating-point-underflow serious-condition vector
function simple-condition warning
So, for all of these, that expression must hold.
Paul
From: Steven M. Haflich
Subject: Re: ANSI CL question: are standard CL class names proper names?
Date:
Message-ID: <3DE86A1C.2000707@alum.mit.edu>
Paul F. Dietz wrote:
>>> My question is: for each such symbol x in the CL package,
>>> is this required to be true:
>>>
>>> (eq x (class-name (find-class x))) ?
>>>
>>> If so, where in the standard does it say that?
> BTW, I did subsequently find this in section 4.3.7 (which, for some
> reason, is tucked under 4.3.6 in the Hyperspec):
>
> Many but not all of the predefined type specifiers have a corresponding
> class with the same proper name as the type. These type specifiers are
> listed in Figure 4-8.
You found this yourself before I could comment, but as a meta
comment, the Franz web site has a search engine for the ANS
that is valuable when researching language lawyer questions like
this. Search for pages that have "proper" and "name" and you
would have quickly found this reference. Lexis for Lispers.
"Paul F. Dietz" <·····@dls.net> writes:
> BTW, I did subsequently find this in section 4.3.7 (which, for some
> reason, is tucked under 4.3.6 in the Hyperspec):
>
> Many but not all of the predefined type specifiers have a corresponding
> class with the same proper name as the type. These type specifiers are
> listed in Figure 4-8.
Is a conforming program permitted to rename those classes with
(SETF CLASS-NAME)? I don't think one should do that, but I
haven't found an explicit restriction in the CLHS. There is one*
for (SETF FIND-CLASS), though.
* Actually at least two: in the FIND-CLASS entry under 7.7, and
as item 16 of 11.1.2.1.2.
From: Tim Bradshaw
Subject: Re: ANSI CL question: are standard CL class names proper names?
Date:
Message-ID: <ey3el93xs55.fsf@cley.com>
* Kent M Pitman wrote:
> "Paul F. Dietz" <·····@dls.net> writes:
>> (eq x (class-name (find-class x))) ?
>>
> I'm pretty sure the standard very carefully does not say this.
I think it would be quite strange if that wasn't true: why would it be
useful to break the class-name->class->class-name consistency? It
seems to me that a much more useful freedom would be that if something
is specified as being of class/type x then it's allowed to be of
proper subclass/subtype of x, and also that is x is a subclass/subtype
of y it might be allowed to not be a direct subclass/subtype of y.
--tim
Tim Bradshaw <···@cley.com> writes:
> * Kent M Pitman wrote:
> > "Paul F. Dietz" <·····@dls.net> writes:
> >> (eq x (class-name (find-class x))) ?
> >>
> > I'm pretty sure the standard very carefully does not say this.
>
> I think it would be quite strange if that wasn't true: why would it be
> useful to break the class-name->class->class-name consistency?
Because of compatibility with other dialects. It's easy enough to get
the class-name operator in each dialect to fake it though, so I guess
it doesn't really matter.
There are a number of classes in ISLISP which are going to be EQ to
classes in ANSI CL but have different names. Fortunately, I don't
think ISLISP offers introspective tools like CLASS-NAME anyway, so the
issue is moot. But if it did, I guess it could just special-case the
names of the classes and use a mapping table to ISLISP names if it
were co-resident with an ANSI CL.
> It
> seems to me that a much more useful freedom would be that if something
> is specified as being of class/type x then it's allowed to be of
> proper subclass/subtype of x,
No, this isn't good enough unless you want to make one of the languages
subservient to the other, and certainly would not win for dispatch.
Also, consider that if floating point overflow is going to sometimes
get signaled, then if language A tries to catch
<floating-point-underflow> but language B tries to catch
floating-point-underflow and these are not just names for the same
thing, you're going to have to always signal the subclass. Suppose that
ISLISP names it <floating-point-underflow> and it's a subclass of
ANSI CL's floating-point-underflow. Then any CL user who
signals floating-point-underflow will not get trapped by someone
looking for <floating-point-underflow>. Basically, there have to be two
names for the same class.
It's easy to make similar cases for method dispatch on fixnums and other
built-in types.
> and also that is x is a subclass/subtype
> of y it might be allowed to not be a direct subclass/subtype of y.
Certainly you want this flexibility but it's not enough.