🚀 go-pugleaf

Is there a (generic) function that when given a parameter-specializer-name will
return the corresponding specializer object? How about a function that returns a
form that when evaluated will return the specializer.?

I want to extend the syntax of DEFMETHOD and other method defining forms in one
of the following ways:

1. A list of the form (SATISFIES <symbol>) is a valid parameter-specializer-name.
The <symbol> would name a function of exactly one argument.
2. A function of exactly one argument is a valid parameter-specializer-name.

In either case, the parameter-specializer-name would resolve to a specializer
object that held a function of exactly one argument. Semantics: at method
dispatch time, the function would be called as a predicate with the corresponding
value of the specialized method argument. If the predicate were to return NIL and
the method were otherwise applicable (e.g., as determined by
COMPUTE-APPLICABLE-METHODS) then the method would no longer be applicable. This 
approach would faciliate dispatch based on, for example, the run-time (or GF 
call-time) value of global variables, user-defined types, etc.

After consulting AMOP, I believe I'll need to do the following to implement such
'satisfies-specializers': define specialized metaobject classes based on
STANDARD-GENERIC-FUNCTION and STANDARD-METHOD; define methods on
COMPUTE-APPLICABLE-METHODS and COMPUTE-APPLICABLE-METHODS-USING-CLASSES; define
methods on SPECIALIZER-DIRECT-GENERIC-FUNCTIONS and SPECIALIZER-DIRECT-METHODS; 
define a class of satisfies-specializers to support everything else. All of this
is no big deal.

However, there seems to be no protocol for converting specializer-names into
specializer objects. AMOP defines an abstract class called SPECIALIZER and a
direct subclass called EQL-SPECIALIZER (table 5.1, p 141), but there is no 
supporting protocol for creating/using such objects. What I need to implement 
satisfies-specializers is a set of functions for generically generating 
specializer objects from a given specializer-name. These functions would
form a 'specializer initialization protocol'. These functions then need to
become a part of the initialization protocol for method objects.

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.

Notes: As implied by the above, any specializer-name that is a list is 
interpreted to be a 'type-specializer-name'. Thus, eql-specializer-names are
no longer unique in their role as list-valued specializer-names. This approach
opens up the possibility of a wide range of method specialization strategies. 
This is also the approach necessary to support extension 1 above. 

If the role of eql-specializers is not to be changed, then we could fall back
on the syntax of extension 2, thereby obviating the need for 
TYPE-SPECIALIZER-OBJECT. The methods on SPECIALIZER-OBJECT would be ammended 
as follows:

SPECIALIZER-OBJECT ((specializer-name symbol)                         [Method]
  This method calls (FIND-CLASS specializer-name).
SPECIALIZER-OBJECT ((specializer-name list))                          [Method]
  This method calls (INTERN-EQL-SPECIALIZER specializer-name).
SPECIALIZER-OBJECT ((specializer-name function))                      [Method]
  This method computes the satisfies-specializer object associated with 
specializer-name.

Comments?
..................................................
                                  Len Charest, Jr.
                 JPL Artificial Intelligence Group
                          charest@aig.jpl.nasa.gov