slot-boundp-using-class broken in LispWorks 8?

[louis77]

I'm having an issue with SLOT-BOUNDP-USING-CLASS in LispWorks 8.

Here is my code:

(use-package :c2cl)

(defclass ping-response () 
   ((message :initarg :message)))

(setf *inst* (make-instance 'ping-response :message "test"))
(setf *class* (class-of *inst*))

(mapcar (lambda (s) 
                  (slot-boundp-using-class *class* *inst* s)) 
               (class-slots *class*))

Error: The slot #<STANDARD-EFFECTIVE-SLOT-DEFINITION MESSAGE 8010142433> 
is missing from #<PING-RESPONSE 801014487B> 
of class #<COMMON-LISP:STANDARD-CLASS PING-RESPONSE 82C03C074B>), 
when reading the value.

In CLOSER-MOP, there is this definition:

(cl:defmethod slot-boundp-using-class
           ((class standard-class) object (slotd standard-effective-slot-definition))
  (declare (optimize (speed 3) (debug 0) (safety 0)
                     (compilation-speed 0)))
  (slot-boundp-using-class
   (load-time-value (class-prototype (find-class 'cl:standard-class)))
   object
   (slot-definition-name slotd)))

in closer-lispworks.lisp.

When I change the lambda list to

(cl:defmethod slot-boundp-using-class
           ((class cl:standard-class) object (slotd standard-effective-slot-definition))

(adding the cl: package to the class specializer) the error is gone.

I found this issue, which might be related:
#18

Which is why I tried to add the USE-PACKAGE :C2CL but that didn't change anything.

For reference, this issue affects the JZON library, which is how I came to it:
Zulu-Inuoe/jzon#49

I'm sure that I'm doing something wrong here and hope that perhaps someone can give me hint.

[Hexstream]

I haven't looked into this, but

(defclass ping-response () ((message :initarg :message)))

(setf *inst* (make-instance 'ping-response :message "test"))

(setf *class* (class-of *inst*))

(mapcar (lambda (s) (slot-boundp-using-class *class* *inst* s)) (class-slots *class*))

would be better written as

(defclass ping-response ()
  ((message :initarg :message)))

(let* ((instance (make-instance 'ping-response :message "test"))
       (class (class-of instance)))
  (mapcar (lambda (slot)
            (slot-boundp-using-class class instance slot))
          (class-slots class)))

[louis77]

I haven't looked into this, but

@Hexstream
How is that related to the issue?

[Hexstream]

Less unrelated warnings makes it easier to investigate the issue, for one thing.

[louis77]

@Hexstream Well, thank you very much for spending 30 seconds to reformat my example code. Greatly appreciated.

[pcostanza]

Try this:

(mapcar (lambda (s) (slot-boundp-using-class *class* *inst* s)) (mapcar 'slot-definition-name (class-slots *class*)))

[pcostanza]

It's normally also not a good idea to call slot-boundp-using-class directly. It's a generic function to define methods on, so slot-boundp can call an optimized version if possible. By calling slot-boundp-using-class directly, you might miss cases where the optimization doesn't apply. So better do this:

(mapcar (lambda (s) (slot-boundp *inst* s)) (mapcar 'slot-definition-name (class-slots *class*)))

[louis77]

Thanks a lot @pcostanza. With your remark I was able to get it working on LispWorks 8. Also, I've submitted a PR to the maintainer of the JZON library.

[Hexstream]

I certainly don't consider myself as big of a MOP expert as @pcostanza, but according to my reading of the (de facto) standard, slot-boundp-using-class absolutely SHOULD accept an effective slot definition as third argument, and SHOULD NOT accept a slot name instead.

I think this ought to be fixed in the MOP implementations and/or closer-mop. (And user code.)

I also think calling slot-boundp-using-class directly is or should be totally legit.
Sometimes it's just convenient, and I don't remember the standard hinting it might not be kosher.

[pcostanza]

@Hexstream Thanks a lot for pointing this out. You are right in the general case. However, in LispWorks, slot-boundp-using-class and friends actually specialize on the slot name, not the effective slot metaclass. When I created Closer to MOP, I had to decide between making things fully compatible, or alternatively, make them compatible only to the extent that they don't hurt performance. I decided for the latter, and that implies that when you call slot-boundp-using-class and friends in LispWorks directly, you won't get compatible behaviour. However, you can define methods on them specialized on effective slot metaclasses, as specified in AMOP, and you will get the correct semantics. For direct calls, always prefer slot-boundp and friends (without -using-class), and you will be fine.

Again, thanks for pointing this out, I should have explained this better immediately.

[Hexstream]

Thank you for the quick and comprehensive reply!

The obvious solution here, of course, would be for LispWorks to just fix their MOP implementation. :)

Given their deep technical expertise, I'm rather flabberghasted that they haven't yet bothered to address this trivial issue in nearly 30 years... and I can't even imagine that this kind of change would break much user code, and the fix could be opt-in for a few years.

More generally, I am rather amazed that closer-mop is still needed in 2023.
It should nearly be a no-op by now... (trivial-mop?)