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

[Cyrus Harmon]

Pascal's reading of the spec would seem to say that cxml-stp needs an  
explicit deftype. Thoughts?

thanks,

cyrus

Begin forwarded message:

> From: Pascal Costanza <pc at p-cos.net>
> Date: December 1, 2008 12:20:55 AM PST
> To: Cyrus Harmon <ch-openmcl at bobobeach.com>
> Cc: openmcl-devel Devel <openmcl-devel at clozure.com>
> Subject: Re: [Openmcl-devel] (setf (find-class ...) ...) problem
>
> 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
>
>
>
>
>
>
>
>