Re: a-to-c

[jac@computer-lab.cambridge.ac.uk]

From Richard Barber, Procyon Research Ltd, Cambridge, UK

>Date: Mon, 11 Jun 90 09:45:44 PDT
>From: "Gregor J. Kiczales" <gregor@parc.xerox.com>
>
>For any standard-metaobject, the implementation of the metaobject
>protocol can be heavily optimized.  For example, a standard generic
>function metaobject doesn't need to ever call compute-discriminating-
>function.  The rules of user specialization prevent there being any
>user-defined applicable methods.
>
>Formally, this optimization can be phrased as:  The implementation is
>permitted to elide a specified call to a specified generic function if
>no portable methods would be applicable to the arguments.

Thanks for making this point more explicit. I had not realized the full
implications of this phrase when I originally read it in the MOP spec.
With this in mind I am now happy with the new spec.

I would guess that users of the MOP might also trip over this, expecting
compute-discriminating-function on a standard generic function to do the
full protocol when in fact the implementor has special-cased away the calls
to compute-applicable-methods and friends. I think perhaps there should be a
warning in the spec for compute-discriminating-function and also for
compute-applicable-methods, compute-applicable-methods-using-classes,
compute-effective-method etc. to say that if the user specializes any of
these functions then compute-discriminating-function may also need to
be specialized.

>   The new specification of compute-discriminating-function is extremely
>   constraining on the way implementations manage method dispatch in
>   generic functions. In particular it forces the implementation to cache
>   lists of applicable methods. We at Procyon have experimented with doing
>   this but found it makes for an intolerable space overhead on small
>   machines.
>
>The description of the method lookup protocol was specifically designed
>to avoid requiring that lists of applicable methods be cached.

I intended my comment to say that an implementation which did not memoize
for standard generic functions would probably be unacceptably slow. But
this objection goes away given the special-casing in standard method
dispatch that is allowed to implementors.

>   ... The new specification of
>   compute-effective-slot-definition states that on each call it creates
>   a new effective slot definition (using make-instance). However, Procyon's
>   current implementation of CLOS shares these objects between a class and
>   those inheriting from it whenever the objects would be equal.
>
>As far as I can tell, there are three ways to address this concern:
>
>1) Find a way to allow compute-effective-slot-definition to return an
>object not created by a call to make-instance.
>...

At Procyon over the last few days we have worked out a way to simulate the
intended uniqueness behaviour of standard effective slot definitions without
actually calling make-instance every time. This solution preserves our current
space savings; we are therefore happy.

Thank you again for your clarifications, Gregor.

Richard