[Openmcl-devel] GF invocation protocol

[Slava Akhmechet]

Gary Byers <gb at clozure.com> writes:

> That's still true; I think that some other things from that
> section of the MOP spec (MAKE-METHOD-LAMBDA ?) are also missing.
This is probably less important as the only implementation that fully
supports make-method-lambda (that I know of) is SBCL. ACL, CLISP, and
CMUCL have no support for it and LispWorks support is patchy. I'm not
sure about others.

> I think that it's fair to say:
>
> 1) Some people need the MOP's GF invocation protocol.
> 2) A lot of people don't.
To be fair, you could probably make this argument about every other
feature of MOP recommendation :)

> Not really.  The way that GF dispatch works in OpenMCL depends on
> some low-level gunk (method functions receive extra invisible/magic
> arguments, generic functions rarely use lists to represent the set
> of arguments that they receive, etc.)
Ok. In this case, how can I obtain the function associated with a
funcallable-instance in OpenMCL (from what I understand there is no
MOP recommendation for doing it)? I'm basically looking for the
opposite of set-funcallable-instance-function. I might be able to
achieve what I want via changing it on affected generic functions
directly.

> This low-level gunk isn't extensible or very close to what the MOP
> specifies, but - all other things being equal and in isolation -
> tends to be faster than doing things in a MOP-compliant way would
> be.  If overhead's introduced here, it has to be removed from some
> other aspects of GF dispatch (or GF dispatch would slow down in all
> cases.)
I'm not sure what you mean. AFAIK most implementations use optimized
routines for standard metaclasses and don't allow (or ignore)
specializations on them. Custom metaclasses, on the other hand, allow
for specialized behavior so that one can opt for customized
functionality at a performance cost without affecting performance of
standard features. Or am I misunderstanding something?

Thanks for your help.

-- 
Regards,
Slava Akhmechet.