Nikodemus Siivola wrote:
> As noted in the bug-report and description, CLHS 7.6.2 does indeed say
> that all _parameter_ specializers are type specifiers.
> However, AMOP says that method-specializers returns a list of specialier
> metaobjects, and I can't find a reference to support the excpetation that
> these were type specifiers.
Indeed there is a missing link between the CLHS and MOP here:
- CLHS 7.6.2 shows how "parameter specializer names" (i.e. the objects
which appear in the source code) are transformed to "parameter
specializers" (i.e. objects which are used behind the curtain and not
- MOP offers a function method-specializers which returns
and nothing guarantees that the specializers from CLHS are the same
as those from MOP.
But I assume we want to make things simple to understand and therefore
identify CLHS specializers with MOP specializers.
> b) the specializer metaobjects be turned into normal type specifiers,
> so that
> (defmethod foo ((x number)) 1)
> (mapcar #'sb-mop:method-specializers *) ; => ((NUMBER))
> ; instead of ((#<BUILT-IN-CLASS NUMBER>))
You don't need to go back from classes to symbols. CLHS 7.6.2 lists
two kinds of specializers: 1. classes, 2. something "which satisfies the
type specifier (eql object)". I cannot parse this formally, but I think
they meant a specializer that is either the same or equivalent to the
type (EQL object).
Now to the MOP. When they say "method-specializers returns
specializer metaobjects", they mean that from these objects you can
call specializer-direct-methods and specializer-direct-generic-functions.
And that these specializers are instances of METAOBJECT, hence also of
> a) the specializer metaobjects be made understandable to TYPEP and
Yes, this seems the most logical way to unify ANSI CL and MOP.
The alternative is to have two different METHOD-SPECIALIZERS functions,
one for ANSI CL which returns a list of classes and (EQL x) lists, and
one for MOP which returns a list of classes and eql-specializer instances.