Re: a-to-c

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

From Richard Barber, Procyon Research Ltd, Cambridge, UK

The new specification for a-c looks fine to me with the exception
of 2 areas:

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.

We found the previous specification of compute-discriminating-function on
page 3-41 of MOP Draft No 10 to be quite satisfactory and have implemented
that. It does not force cacheing applicable methods, and we have developed
an alternative fast technique for method dispatch.

The second area which I am unhappy with (again for space reasons) is
that of effective-slot-definition creation. (I mentioned this in a
message to this group about 2 weeks ago). 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. Following
the new specification and not doing this sharing results in a ***20%***
increase in the size of our complete system image!!

With this in mind, compute-effective-slot-definition should be permitted
to return an existing effective slot definition object where an identical
one exists. A minor consequence is that slot-definition-location
should take an extra argument, the class in which the slot definition
occurs.

The above comments stem from first-hand experience with a full-scale
implementation - I hope we can come to an agreement over them.