[pro] AMOP question: When and where is slot-value-using-class called?

Sun Aug 3 16:50:42 UTC 2014

On 3 Aug 2014, at 09:40, Jean-Claude Beaudoin <jean.claude.beaudoin at gmail.com> wrote:

> Further, if I agree to stop tickling the system where it does not like to be tickled and define a class tracked_class as a subclass of standard-class to be used as a metaclass of the classes I want to track (see slot_mop_strict_tracked_class.lsp here attached), then all of sbcl, clisp, ccl and ACL show the same behavior, properly calling slot-value-using-class both from slot-value or from the slot accessor. Only LispWorks persists in its (erroneous, I think) behavior of calling s-v-u-c only from slot-value.
> I think there is a consensus emerging here.

LispWorks deviates from the slot access protocol in two ways:

- AMOP states that the third argument to s-v-u-c and friends is a slot definition metaobject, not a slot name. In LispWorks, it is in fact a slot name. The CLOS MOP specification specified a slot name as the third argument for a long time, until the last minute before the AMOP book was published, when it was changed to being a slot definition metaobject. LispWorks still adheres to an older version of the specification in this regard.

- One reason why the change from slot name to slot definition metaobject was made is that it allows for better optimization of standard slot accesses that don’t need to go through user-defined methods on s-v-u-c and friends. In LispWorks, you need one extra step to invoke user-defined methods - you have to specify that slot access should not be optimized. In your example, the class definition for ‘foo should look like this to achieve this:

(defclass foo ()
  ((a :accessor foo-a :initarg :a)
   (b :accessor foo-b :initarg :b))
  (:metaclass tracked-class)
  (:optimize-slot-access nil))

Then your modified protocol also works in LispWorks.

It’s usually better to specialize s-v-u-c and friends not only on the first, but also on the third argument, on one of your own slot definition metaobject classes. To make this work, you usually also need to define methods on direct-slot-definition-class and effective-slot-definition-class.

You may be interested in the Closer to MOP project - see http://common-lisp.net/project/closer/ and also available via quicklisp. This is a compatibility library which fixes incompatibilities of the CLOS MOP across different Common Lisp implementations, and makes LispWorks adhere better to the slot access protocol in AMOP. There your code would work unchanged, without the optimize-slot-access flag, and you would not need to define methods several times for different Common Lisp implementations.

> It would be interesting to see if the situation has really changed by now. Is there a "full" MOP implementation now in use and what lessons has it taught?  Most implementations for which I have source code are derived from PCL for their CLOS part and I think that PCL is probably the "not yet full" implementation that was available to the committee back then, wasn't it?

Closer to MOP also has a test suite to check how well a CLOS MOP implementation adheres to AMOP. According to that test suite, ABCL and SBCL are the only CL implementations that fully adhere to AMOP. All other implementations deviate in some aspects.

However, two caveats:

- This is only a statement about how well these implementations fulfill the test suite. There may still be other ways in which they deviate. So take this statement with a grain of salt. (In my experience, SBCL for example still adheres slightly better in practice than ABCL.)

- Many areas in which CLOS MOP implementations don’t adhere don’t seem to matter that much in practice. The most often used protocol seems to be the slot access protocol. Other protocols are either not that useful - for example I see no really useful way how to reliably specialize ensure-generic-function-using-class or ensure-class-using-class, and you can typically achieve the desired effects also otherwise; or they are simply not widely used, like for example make-method-lambda.

My impression is that with Closer to MOP, the most important areas are actually well covered. (However, I may be biased, being the author of Closer to MOP.)

Also keep in mind that it is often useful to consider ways other than using the CLOS MOP to achieve what you want to do. For example, ANSI Common Lisp itself already specifies ways to modify slot accesses through the generic functions slot-missing and slot-unbound, and if this is sufficient for whatever you are trying to do, you might as well stick to that.

> BTW, I noticed in the clisp documentation that they mention a problem with "forward-referenced-class", a case of misdesign they say. At first sight, they seem to have a case. Do they?

I’m not sure if they have a case or not. Specializing ensure-class-using-class is not so useful anyway, and tracking changes from forward-referenced-class to some subclass of standard-class also doesn’t seem to be that useful either, as far as I can tell. If you want to keep track of definitions of classes, it’s better to focus on initialize-instance and reinitialize-instance on subclasses of standard-class, and on finalize-inheritance.

> If they do then the CLOS subcommittee would be vindicated.

That’s exaggerated. The AMOP book has a foreword to the specification which clearly states that this is preliminary work. Unfortunately, the foreword is not reproduced in the HTML version. Here is the text, to put things in perspective:

"In this part of the book, we provide the detailed specification of a metaobject protocol for CLOS. Our work with this protocol has always been rooted in our own implementation of CLOS, PCL. This has made it possible for us to have a user community, which in turn has provided us with feedback on this protocol as it has evolved. As a result, much of the design presented here is well-tested and stable. As this is being written, those parts have been implemented not only in PCL, but in at least three other CLOS implementations we know of. Other parts of the protocol, even though they have been implemented in one form or another in PCL and other implementations, are less well worked out. Work remains to improve not only the ease of use of these protocols, but also the balance they provide between user extensibility and implementor freedom.

"In preparing this specification, it is our hope that it will provide a basis for the users and implementors who wish to work with a metaobject protocol for CLOS. This document should not be construed as any sort of final word or standard, but rather only as documentation of what has been done so far. We look forward to seeing the improvements, both small and large, which we hope this publication will catalyze.

"To this end, for Part II only (chapters 5 and 6), we grant permission to prepare revisions or other derivative works including any amount of the original text. We ask only that you properly acknowledge the source of the original text and explicitly allow subsequent revisions and derivative works under the same terms. To further facilitate improvements in this work, we have made the electronic source for these chapters publicly available; it can be accessed by anonymous FTP from the /pcl/mop directory an arisia.xerox.com.

"In addition to the valuable feedback from users of PCL, the protocol design presented here has benefited from detailed comments and suggestions by the following people: Kim Barrett, Scott Cyphers, Harley Davis, Patrick Dussud, John Foderaro, Richard P. Gabriel, David Gray, David A. Moon, Andreas Paepcke, Chris Richardson, Walter van Roggen, and Jon L. White. We are very grateful to each of them. Any remaining errors, inconsistencies or design deficiencies are the responsibility of the authors alone."

Personally, I don’t believe that forward-referenced-class or ensure-class-using-class are the most important areas that need fixing. There are other issues that are more relevant.

Pascal

--
Pascal Costanza
The views expressed in this email are my own, and not those of my employer.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/pro/attachments/20140803/97bf3c27/attachment.html>