NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/lang/clos/1005

Text File | 1992-11-20 | 5.3 KB | 100 lines

Newsgroups: comp.lang.clos
Path: sparky!uunet!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!ufo!Aig.Jpl.Nasa.Gov!charest
From: [e-mail] (Len Charest)
Subject: Extending syntax/semantics of method specializers
Message-ID: <[e-mail]>
Keywords: metaobject method specializer dispatch
Sender: [e-mail] (For NNTP so rrn will be able to post)
Nntp-Posting-Host: ai-cyclops
Reply-To: [e-mail]
Organization: NASA/Jet Propulsion Laboratory
Date: Fri, 20 Nov 1992 22:12:51 GMT
Lines: 86

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
                          [e-mail]