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

[Pascal Costanza]

Hi there,

Section 4.3.1 defines what a proper name of a class is. The  
restriction is there because otherwise you could have ambiguities in  
the type system. (Two different classes can have the same name, but  
only one can have that name as a proper name.)


Pascal

On 1 Dec 2008, at 06:04, Cyrus Harmon wrote:

> Gary,
>
> Thanks for the thoughtful explanation. Explicitly deftype'ing the
> class first sounds reasonable to me. I've asked the cxml-stp
> developers for their opinion as well.
>
> thanks again,
>
> cyrus
>
> On Nov 30, 2008, at 6:12 PM, Gary Byers wrote:
>
>>
>>
>> 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
>>>
>>>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel

-- 
Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net
Vrije Universiteit Brussel, Programming Technology Lab
Pleinlaan 2, B-1050 Brussel, Belgium