#119: Unexpected CLOS shared slot initialization order --------------------------------------+------------------------------------- Reporter: mevenson | Owner: analysis Type: defect | Status: new Priority: major | Milestone: unscheduled Component: CLOS | Version: 1.0 Keywords: clos unexpected-behavior | --------------------------------------+------------------------------------- Didier Verner writes:
{{{
it seems that until now, I've been relying on a non-standard behavior, namely the fact that shared slots with an :initform are initialized before the first actual class instance is created:
(defclass test () ((slot :allocation :class :initform t)))
(defmethod initialize-instance :before ((test test) &key) (format t "Slot boundp: ~A~%" (slot-boundp test 'slot)))
CL-USER> (make-instance 'test) Slot boundp: NIL #<TEST {C5D3B8}> CL-USER> (make-instance 'test) Slot boundp: T #<TEST {14563D4}> CL-USER>
I just fell on this because every other Common Lisp implementation I've tried gives T and T here. Is it due to the way CLOS is implemented in ABCL, and is there a chance that this can be improved?
}}}
#119: Unexpected CLOS shared slot initialization order -----------------------+---------------------------------------------------- Reporter: mevenson | Owner: analysis Type: defect | Status: new Priority: major | Milestone: unscheduled Component: CLOS | Version: 1.0 Resolution: | Keywords: clos unexpected-behavior -----------------------+----------------------------------------------------
Comment(by mevenson):
Subject broached in comp.lang.lisp:
http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/59817da18...
Side question: Is there a URI for comp.lang.lisp threads that doesn't go through the GOOG?
#119: Unexpected CLOS shared slot initialization order -----------------------+---------------------------------------------------- Reporter: mevenson | Owner: analysis Type: defect | Status: new Priority: major | Milestone: unscheduled Component: CLOS | Version: 1.0 Resolution: | Keywords: clos unexpected-behavior -----------------------+----------------------------------------------------
Comment(by ehuelsmann):
Didier Verna follows up with:
So, after some discussion on cll and pro@, I have some precisions about this. From what I understand of CLHS now, an implementation is not required to initialize a shared slot at class creation time from the initform (so far so good for ABCL).
However, the iniform of a shared slot must be evaluated in the dynamic environment of the defclass call, even if it's not used to initialize the slot right now (see the defclass page). The following test shows that ABCL's behavior is currently incorrect in that regard:
(defclass fungy () ((x :allocation :class :initform (progn (format *debug-io* "~&x initform~%") 6) :initarg :x) (y :initform (progn (format *debug-io* "~&y initform~%") 7) :initarg :y)))
CL-USER(1): (defclass fungy () ...) #<STANDARD-CLASS FUNGY {1AEE513}>
CL-USER(2): (make-instance 'fungy) x initform <========= this is too late y initform #<FUNGY {18C2354}>
#119: Unexpected CLOS shared slot initialization order -----------------------+---------------------------------------------------- Reporter: mevenson | Owner: analysis Type: defect | Status: closed Priority: major | Milestone: unscheduled Component: CLOS | Version: 1.0 Resolution: fixed | Keywords: clos unexpected-behavior -----------------------+---------------------------------------------------- Changes (by ehuelsmann):
* status: new => closed * resolution: => fixed
Comment:
(In [13185]) Fix #119: Incorrect dynamic environment for evaluation of :CLASS allocation slot initforms.
armedbear-ticket@common-lisp.net
-
armedbear