Hello,
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?
Thanks.
On 1/5/11 12:27 , Didier Verna wrote:
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:
Filed as [ticket #119][1].
The CLOS code is split between Java and Lisp, so we need to analyze further: we'll keep you posted.
Thanks for the report!
[1]: http://trac.common-lisp.net/armedbear/ticket/119
Mark Evenson evenson@panix.com wrote:
On 1/5/11 12:27 , Didier Verna wrote:
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:
Filed as [ticket #119][1].
The CLOS code is split between Java and Lisp, so we need to analyze further: we'll keep you posted.
Thanks for the report!
No problem. Just to be clear, I don't think that ABCL's behavior on this is wrong wrt to the standard. It seems to be a corner case. I need to investigate more on this.
Mark Evenson evenson@panix.com wrote:
Filed as [ticket #119][1].
The CLOS code is split between Java and Lisp, so we need to analyze further: we'll keep you posted.
Thanks for the report!
BTW, my name is Verna, not Verner :-)
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}>
Hi Didier,
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
Just committed the fix for this to ABCL trunk.
Bye,
Erik.
armedbear-devel@common-lisp.net