[Openmcl-devel] (setf (find-class ...) ...) problem

[Gary Byers]

On Sun, 30 Nov 2008, Cyrus Harmon wrote:

> I'm trying to use david lichteblau's cxml-stp with ccl and am getting
> errors about undefined types. It seems that ccl doesn't like the
> following:
>
> (setf (find-class 'document-type) (find-class 'cxml-stp:document-type))
>

I assume that you mean something like:

(defclass fruit () ())

(defclass orange (fruit) ())

(setf (find-class 'tangerine) (find-class 'fruit))

(typep (make-instance 'orange) 'tangerine) complains that TANGERINE
isn't a valid type-specifier.

My first reaction was to think that that was a bug, but after looking
at the spec for a while I haven't yet found anything that confirms
that and have found at least one passage that (weakly) contradicts 
that intuition, but it's a bit unclear.

The second paragraph of CLHS 4.3.7 says that "the PROPER name of
every class is a valid type specifier.", then discusses the use
of class objects as type specifiers and notes TYPE-OF's behavior
wrt instances of properly and improperly-named classes.

The next paragraph says "Because the names of classes and class
objects are type specifiers, they can be used in special form THE and
in type declarations."  I think that the clearest reading of that is
something like "Based on what was established in the preceding
paragraph, the PROPER names of classes ... can be used in THE forms
and as type specifiers."  I'd feel better about making that claim
if the language in the third paragraph was a little stronger, but I
find it hard to parse the "because" qualifier as referring to anything
but what's established in the preceding paragraph.

I couldn't find anything else in the spec that was any clearer; the
other things that I found referred to things like "symbols naming
classes defined by DEFCLASS" and their relation to the type system.
(I didn't find anything analogous discussing "symbols established
as class names via (SETF FIND-CLASS).")

I don't see anything in the spec that says that improper class names
-can't- be treated as type specifiers, and it's hard to imagine that
anyone's code would break if CCL's (SETF FIND-CLASS) stopped checking
for proper-namedness in this case, though it's not quite impossible
imagine that.  I'm also perfectly willing to believe that there's
something else in the spec that's more definitive and that contradicts
the interpretation above, but in the absence of that I have to conclude
that code that assumes that (SETF (FIND-CLASS a) c)  S into a valid
type specifier is incorrect (even though it likely "works" in most/all
other implementations.)

I think that there actaully are reasons for the spec's (seeming) insistence
on only considering properly-named classes to be type specifiers (and
that those reasons probably have to do with the compilation model.)  I'm
not sure that those reasons are fully developed, but I don't think that
the spec's distinctions between proper and improper class names are 
arbitrary and accidental, either.




If we all strongly believed that (SETF FIND-CLASS) only made S into
a type specifier if S was the class name of C, then a portable way
of doing this would be something like:

(setf (find-class s) c)
(deftype s () 'c)       ; whatever the "proper name" of C is

CCL actually errs in the expansion of DEFTYPE, because S names a class
(even though it doesn't properly name it and even though it's therefore
not a type-specifier; it'd be more consistent if the expansion of DEFTYPE
did the same kind of check for proper-namedness that (SETF FIND-CLASS) does.

It -does- work to do the DEFTYPE first:

(deftype tangerine () 'orange)
(setf (find-class 'tangerine) (find-class 'orange))

I'm not entirely comfortable in saying that I think that CCL's "right"
about this (at least in trying to adhere to the letter of the spec) and
that other implementations are all wrong.  At the moment, let's just say
that I'm not entirely comfortable (though I think that I'd be a little
closer to comfort if CCL was more consistent, e.g., if DEFTYPE's expansion
only rejected attempts to redefine class-names that the implementation
considered to be type specifiers.)









> a similar problem was discussed a while back where this problem arose
> with GSharp, but I'm not sure what the resolution was. Any suggestions?
>
> thanks,
>
> Cyrus
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>