[closer-devel] GF Invocation Protocol - state of the union?

[Pascal Costanza]

On 10 Sep 2007, at 18:51, Slava Akhmechet wrote:

> Recently I ran into a problem that needs some features from gf
> invocation protocol. I can't seem to figure out the status of this.

The state is in general pretty sad.

> Does compute-discriminating-function work on OpenMCL?

No, not in the "official" versions.

> Some people say it's in 1.1 prerelease. Is this the case? Is it  
> safe to rely on it
> working properly?

I'd be surprised. So far, the documentation always said that the gf  
invocation protocol on MCL and OpenMCL works very differently from  
what is specified in AMOP, and this always sounded to me like a major  
undertaking to change this. But that's just my speculation.

> If not, is there documentation of OpenMCL's protocol
> somewhere? Perhaps they expose other interfaces that allow similar
> semantics?

You would have to ask on the OpenMCL mailing list.

> Is make-method-lambda supported on OpenMCL, ACL and CLisp? If not, do
> they offer alternative interfaces?

No, it's not supported in these implementations, and there are no  
alternative interfaces for that. Actually, only SBCL and LispWorks  
support make-method-lambda (LispWorks with a slightly different API,  
but it's usable).

> I need to inject some code into
> method bodies of generic functions defined with a particular
> metaclass. So far the only way to do it that I can think of (aside
> from totally redefining defmethod or using a different macro
> explicitly) is to specialize make-method-lambda. Are there other ways?

Make-method-lambda is a function that is invoked at macroexpansion  
time to generate the body of a method function. It has to be called  
at macroexpansion time because the body has to be inserted in the  
correct lexical scope - since Common Lisp doesn't support first-class  
lexical environments, there is no other point in time at which to do  
this correctly.

Since that's the case, there is no real loss to do the same thing  
with your own version of a defmethod macro. I have struggled with  
make-method-lambda, etc., for AspectL and ContextL for some time,  
until I decided to define my own define-layered-method macro - and  
this works very well, much better than I initially expected. Based on  
that experience, I think by now that the cases in which make-method- 
lambda is essential are rare. (It would still be a good idea if it  
were more widely supported, but I guess the main reason why it's not  
is that it complicates the optimization model for generic functions a  
lot.)

It's a little bit easier to understand why your own method definition  
macros should typically be sufficient if you realize that there is  
actually a serious omission in CLOS itself: You can define a default  
method class to use in defgeneric, but there is no way to use a  
different method class in defmethod (which would actually be useful).  
However, let's assume that such a way would exist, then it's clear  
that the following two ways to define a specific kind of method don't  
really differ that much:

(defmethod foo (x y z)
   (declare (method-class layered-method))
   ...)

(define-layered-method foo (x y z)
   ...)

Both declare the use of a specific kind of method lexically, and both  
versions are mainly processed at macroexpansion time.

(Things become more interesting if you actually also modify the  
parameter list for method functions by using complementary method  
classes and method combinations, but that would only work in SBCL and  
nowhere else, to the best of my knowledge - and that would indeed be  
something that's hard to achieve with just macros.)

As a general rule of thumb: If what you want to do can be achieved by  
macros, it's in general probably better to indeed use macros. The  
CLOS MOP is interesting for cases where there are significant changes  
of runtime behavior which depend on dynamic properties of a program.  
That happens, for example, when you want your own kinds of classes,  
generic functions, etc., work well in conjunction with CLOS's  
redefinition features, among other things. But that's not the case  
for processing method bodies, because for CLOS, a method body is  
always "static" after a method metaobject has been created.

> And finally, is it possible/planned to bridge the gap for these
> features in Closer?

I have made an attempt to do this for the generic function invocation  
protocol, but this amounts to essentially reimplementing almost all  
of it, including the processing of method combinations, which is very  
hairy, especially when you want good performance.

So no, this won't happen because that's unreasonable. The only chance  
you have is to bug the vendors to provide better support for the CLOS  
MOP in that area.


Pascal

-- 
Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net
Vrije Universiteit Brussel, Programming Technology Lab
Pleinlaan 2, B-1050 Brussel, Belgium