Re: MOP question for language lawyers: can you specialize on standard-class

"Pascal Costanza (as pc at p-cos dot net)" <[email protected]> Thu, 14 May 2026 07:18:14 +0200
Newsgroups gmane.lisp.lispworks.general
Message-ID <[email protected]>
I wanted to respond to this thread already for a bit longer, but didn't find the time.

It's important to keep in mind that the CLOS MOP "specification" in AMOP is not of the same level of quality as the ANS CL specification. It is in places not consistent with ANSI CL, and even not fully consistent with itself. It simply didn't go through the same amount of vetting as ANSI Cl. It is somewhat deceiving how close it looks and feels like the ANSI CL spec, but it is actually "just" a draft. (Of course an extremely good one, nonetheless.)

>From the time when I was doing the investigations for the Closer to MOP library, I recall reading in some mailing list archive where the CLOS MOP was discussed that the intention (!) was that s-v-u-c methods should only be applicable if specialized on at least either the class parameter or the slot parameter, but not if only on the object parameter. That is, if class and slot would both be specialized on standard-class or standard-effective-slot-definition, a method would not be valid. This makes sense because it gives a CLOS implementation a lot more wiggle room for optimizations. I also recall that this was a late discovery - I can only speculate, but my guess is that it was too late to make the necessary edits for AMOP. However, this is in line with what I have seen in some CLOS implem
 entations - most CLOS implementations derive from PCL, and it seems to me that PCL itself also effectively behaved like that.

Please take all of these statements of mine with a big bag of salt, it has been a while since I have last looked at the history of all of this. Somebody should dig up the relevant emails from that mailing list again to verify this.

However, anyway, I would strongly recommend sticking with the spirit of the statements: You are implementing meta-level extensions to CLOS, so you should be specializing for meta-level classes. The object parameter for s-v-u-c is not at the meta-level. For base level extensions, ANSI CL's slot-missing and slot-unbound are more often than not good enough. (Yeah, it's a bit murky to call that base level... ;)

I hope that makes sense...

Pascal

> On 7 May 2026, at 14:49, Madhu (as enometh at meer dot net) <[email protected]> wrote:
> 
> * Martin Simmons <[email protected]> :
> Wrote on Tue, 21 Apr 2026 18:09:05 +0100:
> 
>> Yes, I don't see why not.  In fact, I think you have to specialize on the
>> class argument if you don't have a specific metaclass because otherwise the
>> AMOP method that specializes on standard-class (and doesn't specialize on
>> object) will be the most applicable method and your method will never be
>> called.
>> 
>> What are your concerns about it?
> 
> It doesn't work on all implementations.  SLOT-VALUE doesn't go through
> slot-value-using-class in say, ECL and CCL in the following example.
> 
> (require 'closer-mop)
> 
> (defclass foo ()
>  ((slot-1 :initform 10)
>   (slot-2 :initform 20))
> #+lispworks(:optimize-slot-access nil))
> 
> (defmethod c2mop:slot-value-using-class ((class standard-class) (obj foo) slot)
>  (let ((slot-name (etypecase slot
>             (symbol slot)
>             (c2mop:standard-effective-slot-definition
>              (c2mop:slot-definition-name slot)))))
>    (cond ((eql slot-name 'slot-2) 42)
>      (t (call-next-method)))))
> 
> (setq $f (make-instance 'foo))
> (slot-value $f 'slot-2) ; 20 on ecl,ccl,
> 
> (c2mop:slot-value-using-class (class-of $f)
>                  $f
>                  (find 'slot-2
>                    (c2mop:class-slots (class-of $f))
>                    :key
>                    #'c2mop:slot-definition-name)) ;42
> 
> 
> Are the implementation justified in ignoring s-v-u-c for standard
> slots?  I can't tell.
> 
> BTW on another note, if you elide the slot slot-2 from defclass foo,
> the code still works in lispworks, but all other implementations throw
> a slot-missing error.
> 
> If in the future lispworks changes the signature of s-v-u-c to use a
> slot-definition object instead of a symbol, will it still be justified
> in not throwing a slot-missing error?, ---Regards, Madhu
> 
> [Rainer Joswig's answer in
> https://stackoverflow.com/questions/17554370/how-to-define-a-structure-in-lisp-with-arbitrary-number-of-args
> works only with lw, on account of the slot-missing behaviour]
> 
> _______________________________________________
> Lisp Hug - the mailing list for LispWorks users
> [email protected]
> http://www.lispworks.com/support/lisp-hug.html

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
[email protected]
http://www.lispworks.com/support/lisp-hug.html