From: Slava A. <cof...@gm...> - 2007-08-22 05:19:55
|
Calling 'class-prototype' on built in types in SBCL 1.0.7/Linux/X86 gives strage results: (sb-mop:class-prototype (find-class 'integer)) => 42 (sb-mop:class-prototype (find-class 'symbol)) => #:MU So far so good. But now... (sb-mop:class-prototype (find-class 'string)) => 42 (sb-mop:class-prototype (find-class 'vector)) => 42 I saw the following news entry for version 0.8.2: "SB-MOP:CLASS-PROTOTYPE on built-in-classes returns an instance of the class in more cases than previously." I guess prototype values for some common built in classes were missed. I'd be happy to hack this in for the broken types I can discover but I'd need some guidance. It looks like the default value (42) is set in src/pcl/defs.lisp when defining sb-pcl::*built-in-classes*. Values for specific classes are set in src/code/class.lisp when setting sb-kernel::*built-in-classes*. Should the prototype values be inherited (array has one, so why doesn't vector reuse that?) I think that would take care of most offending cases. If so, how could that be done? If not, what should be the hardcoded values? Given that the default one is 42 and the one for symbols is #:MU, should prototype for strings contain some quote from Principia Mathematica? :) -- Regards, Slava Akhmechet. |
From: Vyacheslav A. <cof...@gm...> - 2007-08-26 05:26:00
|
On 8/22/07, Slava Akhmechet <cof...@gm...> wrote: > Calling 'class-prototype' on built in types in SBCL 1.0.7/Linux/X86 > gives strage results: > > (sb-mop:class-prototype (find-class 'integer)) => 42 > (sb-mop:class-prototype (find-class 'symbol)) => #:MU > > So far so good. But now... > > (sb-mop:class-prototype (find-class 'string)) => 42 > (sb-mop:class-prototype (find-class 'vector)) => 42 I created a patch for this that I attach to this email. Basically I added sane values for prototype of sequence, vector, string, simple-string, and list. I also added unit tests and later ran full regression tets to make sure I didn't break anything. Let me know if there's a better way to do something. Hope people find this useful. Regards, Slava Akhmecet |
From: Christophe R. <cs...@ca...> - 2007-08-26 21:07:14
|
"Vyacheslav Akhmechet" <cof...@gm...> writes: > On 8/22/07, Slava Akhmechet <cof...@gm...> wrote: >> Calling 'class-prototype' on built in types in SBCL 1.0.7/Linux/X86 >> gives strage results: >> >> (sb-mop:class-prototype (find-class 'integer)) => 42 >> (sb-mop:class-prototype (find-class 'symbol)) => #:MU >> >> So far so good. But now... >> >> (sb-mop:class-prototype (find-class 'string)) => 42 >> (sb-mop:class-prototype (find-class 'vector)) => 42 > I created a patch for this that I attach to this email. Basically I > added sane values for prototype of sequence, vector, string, > simple-string, and list. I also added unit tests and later ran full > regression tets to make sure I didn't break anything. Let me > know if there's a better way to do something. Did you not get my message on closer, in a reply to this same issue? The problem is that class-prototype really needs to return a direct instance, which is not possible for the classes that you name. Probably an actual error (slot-unbound or maybe a variant with a reference to documentation) would be better behaviour, if that's legal. Cheers, Christophe |
From: Vyacheslav A. <cof...@gm...> - 2007-08-26 21:40:38
|
On 8/26/07, Christophe Rhodes <cs...@ca...> wrote: > Did you not get my message on closer, in a reply to this same issue? Ah, sorry, I didn't realize you were from sbcl-devel. I thought there were no responses from the devs so I just sent a patch. > The problem is that class-prototype really needs to return a direct > instance. Like 42? :) BTW, does that mean that CLISP and CMUCL which return "approximations" of direct instances do not conform to the spec? Did the SBCL team remove this from CMUCL because of a stricter interpretation of the spec, or was it added to CMUCL after the fork? Regards, Slava Akhmechet |
From: Pascal C. <pc...@p-...> - 2007-08-28 09:35:10
|
On 26 Aug 2007, at 23:40, Vyacheslav Akhmechet wrote: > On 8/26/07, Christophe Rhodes <cs...@ca...> wrote: >> Did you not get my message on closer, in a reply to this same issue? > Ah, sorry, I didn't realize you were from sbcl-devel. I thought there > were no responses from the devs so I just sent a patch. > >> The problem is that class-prototype really needs to return a direct >> instance. > Like 42? :) BTW, does that mean that CLISP and CMUCL which return > "approximations" of direct instances do not conform to the spec? Did > the SBCL team remove this from CMUCL because of a stricter > interpretation of the spec, or was it added to CMUCL after the fork? The idea that there could be a more or less strict interpretation of the CLOS MOP specification is a misunderstanding. The spec is simply underspecified, so an implementation can essentially do whatever it wants, including returning 42 for any built in class. Granted, it is a somewhat surprising behavior. ;-) Pascal -- Pascal Costanza, mailto:pc...@p-..., http://p-cos.net Vrije Universiteit Brussel, Programming Technology Lab Pleinlaan 2, B-1050 Brussel, Belgium |