The following CLOS code works in CLISP (2.46) but gives an error in
SBCL (1.0.16) and CMUCL (19e). I list the code and SBCL's error
below. If one is supposed to be able to create (in effect) meta
classes in CLOS, this error should not occur. Whatever SBCL is
asking me to do can't possibly jive with the spec. Help would
be greatly appreciated.
(Yes, I know about :allocation :class)
Thanks.
Blake McBride
(defclass meta-class1 (standard-class)
(cv1 cv2 cv3)
(:metaclass standard-class))
(defclass class1 (standard-object)
(iv1 iv2 iv3)
(:metaclass meta-class1))
debugger invoked on a SIMPLE-ERROR:
The class #<STANDARD-CLASS STANDARD-OBJECT> was specified as a
super-class of
the class #<META-CLASS1 CLASS1>, but the meta-classes
#<STANDARD-CLASS STANDARD-CLASS> and #<STANDARD-CLASS META-CLASS1> are
incompatible. Define a method for SB-MOP:VALIDATE-SUPERCLASS to
avoid this
error.
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [ABORT] Exit debugger, returning to top level.
((SB-PCL::FAST-METHOD SHARED-INITIALIZE :AFTER (SB-PCL::STD-CLASS T))
#(17 NIL 5 NIL)
#<unavailable argument>
#<META-CLASS1 CLASS1>
T)[:EXTERNAL]
0]
Blake McBride wrote:
>
> The following CLOS code works in CLISP (2.46) but gives an error in
> SBCL (1.0.16) and CMUCL (19e). I list the code and SBCL's error
> below. If one is supposed to be able to create (in effect) meta
> classes in CLOS, this error should not occur. Whatever SBCL is
> asking me to do can't possibly jive with the spec.
The spec does not cover metaclasses. AMOP is not a standard, and cannot
be used as a reference reliably. I did not dig into it after it got a
decent MOP, but the feeling I had was that it was really well done, so
perhaps you are just running into stuff other implementations handle
differently.
Help would
> be greatly appreciated.
>
> (Yes, I know about :allocation :class)
>
> Thanks.
>
> Blake McBride
>
>
> (defclass meta-class1 (standard-class)
> (cv1 cv2 cv3)
> (:metaclass standard-class))
>
> (defclass class1 (standard-object)
> (iv1 iv2 iv3)
> (:metaclass meta-class1))
>
> debugger invoked on a SIMPLE-ERROR:
> The class #<STANDARD-CLASS STANDARD-OBJECT> was specified as a
> super-class of
> the class #<META-CLASS1 CLASS1>, but the meta-classes
> #<STANDARD-CLASS STANDARD-CLASS> and #<STANDARD-CLASS META-CLASS1> are
> incompatible. Define a method for SB-MOP:VALIDATE-SUPERCLASS to avoid
> this
> error.
Did you do what the error message said and define the suggested method?
You should. This is a sign, I guess, of where these CLs differ from CLisp.
kt
Kenny wrote:
> Blake McBride wrote:
>>
>> The following CLOS code works in CLISP (2.46) but gives an error in
>> SBCL (1.0.16) and CMUCL (19e). I list the code and SBCL's error
>> below. If one is supposed to be able to create (in effect) meta
>> classes in CLOS, this error should not occur. Whatever SBCL is
>> asking me to do can't possibly jive with the spec.
>
> The spec does not cover metaclasses. AMOP is not a standard, and cannot
> be used as a reference reliably. I did not dig into it after it got a
Oops, I meant to bind "it" to "CLisp" somewhere in there.
kt
> decent MOP, but the feeling I had was that it was really well done, so
> perhaps you are just running into stuff other implementations handle
> differently.
>
> Help would
>> be greatly appreciated.
>>
>> (Yes, I know about :allocation :class)
>>
>> Thanks.
>>
>> Blake McBride
>>
>>
>> (defclass meta-class1 (standard-class)
>> (cv1 cv2 cv3)
>> (:metaclass standard-class))
>>
>> (defclass class1 (standard-object)
>> (iv1 iv2 iv3)
>> (:metaclass meta-class1))
>>
>> debugger invoked on a SIMPLE-ERROR:
>> The class #<STANDARD-CLASS STANDARD-OBJECT> was specified as a
>> super-class of
>> the class #<META-CLASS1 CLASS1>, but the meta-classes
>> #<STANDARD-CLASS STANDARD-CLASS> and #<STANDARD-CLASS META-CLASS1> are
>> incompatible. Define a method for SB-MOP:VALIDATE-SUPERCLASS to
>> avoid this
>> error.
>
> Did you do what the error message said and define the suggested method?
> You should. This is a sign, I guess, of where these CLs differ from CLisp.
>
> kt
On Jul 29, 3:32 am, Blake McBride <·····@mcbride.name> wrote:
> The following CLOS code works in CLISP (2.46) but gives an error in
> SBCL (1.0.16) and CMUCL (19e). I list the code and SBCL's error
> below. If one is supposed to be able to create (in effect) meta
> classes in CLOS, this error should not occur. Whatever SBCL is
> asking me to do can't possibly jive with the spec. Help would
> be greatly appreciated.
>
> (Yes, I know about :allocation :class)
>
> Thanks.
>
> Blake McBride
>
> (defclass meta-class1 (standard-class)
> (cv1 cv2 cv3)
> (:metaclass standard-class))
>
> (defclass class1 (standard-object)
> (iv1 iv2 iv3)
> (:metaclass meta-class1))
>
> debugger invoked on a SIMPLE-ERROR:
> The class #<STANDARD-CLASS STANDARD-OBJECT> was specified as a
> super-class of
> the class #<META-CLASS1 CLASS1>, but the meta-classes
> #<STANDARD-CLASS STANDARD-CLASS> and #<STANDARD-CLASS META-CLASS1> are
> incompatible. Define a method for SB-MOP:VALIDATE-SUPERCLASS to
> avoid this
> error.
>
> Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
>
> restarts (invokable by number or by possibly-abbreviated name):
> 0: [ABORT] Exit debugger, returning to top level.
>
> ((SB-PCL::FAST-METHOD SHARED-INITIALIZE :AFTER (SB-PCL::STD-CLASS T))
> #(17 NIL 5 NIL)
> #<unavailable argument>
> #<META-CLASS1 CLASS1>
> T)[:EXTERNAL]
> 0]
If you look at SBCL's output, you'll find the answer: "Define a method
for SB-MOP:VALIDATE-SUPERCLASS to avoid this error". I don't remember
the exact method signature of VALIDATE-SUPERCLASS, but all you need is
(IIRC) specialize a parameter on your metaclass and have the method
simply return T.
hth,
Alessio
Blake McBride wrote:
>
> The following CLOS code works in CLISP (2.46) but gives an error in
> SBCL (1.0.16) and CMUCL (19e). I list the code and SBCL's error
> below. If one is supposed to be able to create (in effect) meta
> classes in CLOS, this error should not occur. Whatever SBCL is
> asking me to do can't possibly jive with the spec. Help would
> be greatly appreciated.
Clisp should actually give an error here as well.
You have to define a method like this:
(defmethod validate-superclass
((class meta-class1)
(superclass standard-class))
t)
This indicates that instances of meta-class1 can inherit from instances
of standard-class. In other words, this declares those two metaclasses
as compatible - metaclasses are in general semantically not compatible,
that's why the CLOS MOP requires such a declaration.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Blake McBride wrote:
>>
>> The following CLOS code works in CLISP (2.46) but gives an error in
>> SBCL (1.0.16) and CMUCL (19e). I list the code and SBCL's error
>> below. If one is supposed to be able to create (in effect) meta
>> classes in CLOS, this error should not occur. Whatever SBCL is
>> asking me to do can't possibly jive with the spec. Help would
>> be greatly appreciated.
>
> Clisp should actually give an error here as well.
>
> You have to define a method like this:
>
> (defmethod validate-superclass
> ((class meta-class1)
> (superclass standard-class))
> t)
>
> This indicates that instances of meta-class1 can inherit from instances
> of standard-class. In other words, this declares those two metaclasses
> as compatible - metaclasses are in general semantically not compatible,
> that's why the CLOS MOP requires such a declaration.
>
>
> Pascal
>
That doesn't generally work. What I found that does (in CLISP, CMUCL, &
SBCL) is:
#+:sbcl (defmethod sb-mop:validate-superclass
((sub-class meta-class1) (super-class standard-class))
t)
#+:cmu (defmethod pcl:validate-superclass
((sub-class meta-class1) (super-class standard-class))
t)
Blake McBride
Blake McBride <·····@mcbride.name> writes:
> Pascal Costanza wrote:
>> Blake McBride wrote:
>>>
>>> The following CLOS code works in CLISP (2.46) but gives an error in
>>> SBCL (1.0.16) and CMUCL (19e). I list the code and SBCL's error
>>> below. If one is supposed to be able to create (in effect) meta
>>> classes in CLOS, this error should not occur. Whatever SBCL is
>>> asking me to do can't possibly jive with the spec. Help would
>>> be greatly appreciated.
>> Clisp should actually give an error here as well.
>> You have to define a method like this:
>> (defmethod validate-superclass
>> ((class meta-class1)
>> (superclass standard-class))
>> t)
>> This indicates that instances of meta-class1 can inherit from
>> instances of standard-class. In other words, this declares those two
>> metaclasses as compatible - metaclasses are in general semantically
>> not compatible, that's why the CLOS MOP requires such a declaration.
>> Pascal
>>
>
> That doesn't generally work. What I found that does (in CLISP, CMUCL,
> & SBCL) is:
>
> #+:sbcl (defmethod sb-mop:validate-superclass
> ((sub-class meta-class1) (super-class standard-class))
> t)
> #+:cmu (defmethod pcl:validate-superclass
> ((sub-class meta-class1) (super-class standard-class))
> t)
Yes, that's where a little word like "like" makes a difference. Yes,
I know, something like "like" making a difference...
Personnaly, I would write:
(defmethod closer-mop:validate-superclass ((class meta-class1)
(superclass standard-class))
t)
--
__Pascal Bourguignon__
Blake McBride wrote:
> Pascal Costanza wrote:
>> Blake McBride wrote:
>>>
>>> The following CLOS code works in CLISP (2.46) but gives an error in
>>> SBCL (1.0.16) and CMUCL (19e). I list the code and SBCL's error
>>> below. If one is supposed to be able to create (in effect) meta
>>> classes in CLOS, this error should not occur. Whatever SBCL is
>>> asking me to do can't possibly jive with the spec. Help would
>>> be greatly appreciated.
>>
>> Clisp should actually give an error here as well.
>>
>> You have to define a method like this:
>>
>> (defmethod validate-superclass
>> ((class meta-class1)
>> (superclass standard-class))
>> t)
>>
>> This indicates that instances of meta-class1 can inherit from
>> instances of standard-class. In other words, this declares those two
>> metaclasses as compatible - metaclasses are in general semantically
>> not compatible, that's why the CLOS MOP requires such a declaration.
>>
>>
>> Pascal
>>
>
> That doesn't generally work. What I found that does (in CLISP, CMUCL, &
> SBCL) is:
>
> #+:sbcl (defmethod sb-mop:validate-superclass
> ((sub-class meta-class1) (super-class standard-class))
> t)
> #+:cmu (defmethod pcl:validate-superclass
> ((sub-class meta-class1) (super-class standard-class))
> t)
Yep, the CLOS MOP is not part of ANSI Common Lisp, and the CLOS MOP
specification doesn't mandate the name of the package from where you can
import the CLOS MOP symbols. So that's implementation-dependent.
You can use the Closer to MOP compatibility layer to work around that.
See my footer.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/