cxml-devel

Download

cxml-devel@common-lisp.net

December 2008

1 participants
2 discussions

[cxml-devel] Fwd: [Openmcl-devel] (setf (find-class ...) ...) problem
by Cyrus Harmon 01 Dec '08

01 Dec '08

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(a)p-cos.net> > Date: December 1, 2008 12:20:55 AM PST > To: Cyrus Harmon <ch-openmcl(a)bobobeach.com> > Cc: openmcl-devel Devel <openmcl-devel(a)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(a)clozure.com >>>> http://clozure.com/mailman/listinfo/openmcl-devel >>>> >>>> >> >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel(a)clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel > > -- > Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net > Vrije Universiteit Brussel, Programming Technology Lab > Pleinlaan 2, B-1050 Brussel, Belgium > > > > > > > >

1 0

[cxml-devel] cxml-stp patch for ccl
by Cyrus Harmon 01 Dec '08

01 Dec '08

the following patch allows cxml-stp to compile under ccl: diff --git a/classes.lisp b/classes.lisp index 026cfc3..db70b47 100644 --- a/classes.lisp +++ b/classes.lisp @@ -86,6 +86,9 @@ @see-slot{system-id} @see-slot{public-id} @see-slot{internal-subset}")) +#+ccl +(deftype document-type () 'cxml-stp:document-type) + (setf (find-class 'document-type) (find-class 'cxml-stp:document- type)) (defclass cxml-stp:document (parent-node) () The problem is that (setf (find-class ...) ...) doesn't create the type under ccl. Arguably, this shouldn't be necessary. But, as Gary Byers has pointed out on openmcl-devel, that point is arguable and he makes a decent case as to why this shouldn't work. thoughts? thanks, Cyrus

1 0