🚀 go-pugleaf

>>>>> On Fri, 20 Nov 1992 22:12:51 GMT, charest@Aig.Jpl.Nasa.Gov (Len
Charest) said:
Proposal: I propose the following additions to the MOP (as described in AMOP). 
If the processing of DEFMETHOD (as described on p 149-150 in AMOP) were 
revised to include use of these functions then I'd have a portable way of 
writing satisfies-specializers.

SPECIALIZER-OBJECT (specializer-name)                       [Generic Function]
  This generic function returns the specializer object associated with
specializer-name. 
SPECIALIZER-OBJECT ((specializer-name symbol)                         [Method]
  This method calls (FIND-CLASS specializer-name).
SPECIALIZER-OBJECT ((specializer-name list))                          [Method]
  This method calls (TYPE-SPECIALIZER-OBJECT (CAR specializer-name) (CDR
specializer-name)). The value returned by TYPE-SPECIALIZER-OBJECT is the value
returned by this function.

TYPE-SPECIALIZER-OBJECT (type-specifier subsidiary-info)    [Generic Function]
  This generic function returns the specializer object associated with the
given type-specifier and its subsidiary-info.
TYPE-SPECIALIZER-OBJECT ((type-specifier (eql 'eql)) subsidiary-info  [Method]
  This method calls (INTERN-EQL-SPECIALIZER (CAR subsidiary-info)).
TYPE-SPECIALIZER-OBJECT ((type-specifier (eql 'satisfies))            [Method]
                         subsidiary-info)
  This method computes the satisfies-specializer object associated with the 
given subsidiary-info.
<<<<<<<<<[end of cite]


Hi Len;

   I think you've hit on a good area in which specialization could be
beefed up.  One thought occurred to me when wishing for more
specialization power of this sort a while back:

   Since the EQL specializer has its roots in the EQL type specifier,
why not allow specialization using any type specifier such as MEMBER,
OR, (INTEGER 5 10), etc.  EQL would become just one of many type
checking specializers which would conceivably even share the same
specializer metaobject.  This specializer might be named something
like TYPE-SPECIFIER-SPECIALIZER and would replace and subsume
EQL-SPECIALIZER.

   The implementation would simply call
(TYPEP <gen-fun-arg> <type-specifier>) during generic dispatch.  This
approach would eliminate the need for the TYPE-SPECIALIZER-OBJECT
generic function.

   Any further thoughts?  Perhaps I'm unaware of reasons for allowing
EQL-SPECIALIZER to be its own metaobject or any number of other things
;^>.


                                   Eric Peterson (speaking for myself)
                                   Systems Research and Applications
                                   2000 15th Street North
                                   Arlington, VA 22201
                                   USA
                                   peterson@sra.com
                                   (703) 558-7644
                                   Fax:  (703) 558-4723