Gerd Moellmann wrote:
>
> Gerardo Sarria <[EMAIL PROTECTED]> writes:
>
> > * (defclass omclass (standard-class) ())
> > * (defclass OMGenericFunction (standard-generic-function OMBasicObject)
> > ()
> > (:metaclass omclass))
>
> I'd say MCL has a bug if the above works there.
>
the above does work in mcl. more pertinently, the code below works:
(defGeneric omtest (a s)
(:method (a s) (list a s))
(:generic-function-class omgenericfunction))
#<OMGENERICFUNCTION OMTEST #x683B9D6>
? (omtest 1 2)
(1 2)
? (describe #'omtest)
#<OMGENERICFUNCTION OMTEST #x683B9D6>
Name: OMTEST
Arglist (analysis): (CCL::ARG-0 CCL::ARG-1)
Methods: (#<STANDARD-METHOD OMTEST (T T)>)
#<STANDARD-METHOD OMTEST (T T)>
Class: #<OMCLASS OMGENERICFUNCTION>
Wrapper: #<CCL::CLASS-WRAPPER OMGENERICFUNCTION #x6855F76>
Forwarded to: #((#<STANDARD-METHOD OMTEST (T T)>) NIL #<CCL::STANDARD-INSTANCE
#x685614E> 0
#<OMGENERICFUNCTION OMTEST #x683B9D6> 0 #<CCL::CLASS-WRAPPER FIXNUM
#x458F636>
#<METHOD-FUNCTION OMTEST (T T)> #<Unbound> NIL)
Instance slots
METHOD-COMBINATION: #<STANDARD-METHOD-COMBINATION STANDARD>
METHOD-CLASS: #<STANDARD-CLASS STANDARD-METHOD>
? (class-precedence-list (find-class 'OMGENERICFUNCTION))
(#<OMCLASS OMGENERICFUNCTION> #<FUNCALLABLE-STANDARD-CLASS STANDARD-GENERIC-FUNCTION>
#<FUNCALLABLE-STANDARD-CLASS GENERIC-FUNCTION> #<STANDARD-CLASS METAOBJECT>
#<STANDARD-CLASS
CCL::FUNCALLABLE-STANDARD-OBJECT> #<STANDARD-CLASS OMBASICOBJECT> #<STANDARD-CLASS
STANDARD-OBJECT> #<STANDARD-CLASS FUNCTION> #<BUILT-IN-CLASS T>)
?
whether it is a bug is a matter of perspective.
mcl has (for better or worse) has never claimed conformance to a "standard" mop. (i
leave the quotes to stand for themselves). what is a bit more surprising, it is not
apparent
from the standard's description of defgeneric, that there is any requirement on the
constitution of the class specified as the value of the :generic-function-class
option. there is
mention that the class must be compatible with an original in the event that a
redefinition effects a change-class, but it does not say what "compatible" means.
that mcl relaxes a common constraint on class pedigree to require only that the class
specialize funcallable-standard-class, as demonstrated by:
? (defclass not-a-function () ())
#<STANDARD-CLASS NOT-A-FUNCTION>
? (defGeneric omfail (a s)
(:method (a s) (list a s))
(:generic-function-class not-a-function))
> Error: No applicable method for args:
> (#<NOT-A-FUNCTION #x697570E> STANDARD NIL)
> to #<STANDARD-GENERIC-FUNCTION CCL::FIND-METHOD-COMBINATION #x4598346>
> While executing: #<CCL::STANDARD-KERNEL-METHOD NO-APPLICABLE-METHOD (T)>
> Type Command-. to abort.
See the Restarts� menu item for further choices.
1 >
does not constitute a bug, although one could well argue for a better diagnostic.
mr sarria,
this is just one of those things which one must be aware of when porting
mcl-originating code to a lisp which has a more conventional mop. one simply defines
the necessary methods
for validate-superclass. under mcl they never get called but they keep a mop which
demands them from getting upset.
should you make use of mop-based introspection, you will also observe that mcl's
representations for meta data are somewhat unconventional.
> I think the error message is quite explicit about what the problem is,
> if a bit badly formatted. What explanation do you expect?
...
