From: Larry D'A. <smo...@el...> - 2005-07-24 06:58:35
|
This is a modified bit of code I found on c.l.l (defclass fn () ((x :initarg :x)) (:metaclass sb-mop:funcallable-standard-class)) (defmethod initialize-instance :after ((fn fn) &rest initargs &key &allow-other-keys) (declare (ignore initargs)) (let ((n (slot-value fn 'x))) (format t "FOOOOOOO ~A~%" n) (format t "Initializing ~A...~%" fn) (sb-mop:set-funcallable-instance-function fn (lambda (x) (format t "Calling ~A with ~A. also ~A~%" fn x n )))) (format t "Initialized ~A.~%" fn)) (funcall (make-instance 'fn :x 7) 42) this is what it prints FOOOOOOO 7 Initializing #<FN {9685745}>... Initialized #<FN {9685745}>. Calling #<WRAPPER #<SB-MOP:FUNCALLABLE-STANDARD-CLASS FN> {9A3B841}> with 42. also #<CLOSURE (LAMBDA (X)) {9685E55}> how did n's value change from 7 to #<CLOSURE (LAMBDA (X)) {9685E55}> ?? I get other bizare results any time I try to access slot values of a funcallable instance inside the actual function attached to that instance. Am I doing something illgal here or is this a bug? --larry |
From: Christophe R. <cs...@ca...> - 2005-07-24 12:57:41
|
Larry D'Anna <smo...@el...> writes: > (sb-mop:set-funcallable-instance-function fn > (lambda (x) > (format t "Calling ~A with ~A. also ~A~%" fn x n )))) > > I get other bizare results any time I try to access slot values of a > funcallable instance inside the actual function attached to that > instance. Am I doing something illgal here or is this a bug? It's a bug, I'm afraid. SBCL's calling convention for funcallable-instances is different from that for ordinary functions, so all sorts of things go haywire in the above case. As a non-portable workaround, you can use sb-kernel:instance-lambda instead of cl:lambda, above. Cheers, Christophe |
From: Pascal C. <pc...@p-...> - 2005-07-28 14:37:27
|
On 24 Jul 2005, at 13:54, Christophe Rhodes wrote: > Larry D'Anna <smo...@el...> writes: > >> (sb-mop:set-funcallable-instance-function fn >> (lambda (x) >> (format t "Calling ~A with ~A. also ~A~%" fn x n )))) >> >> I get other bizare results any time I try to access slot values of a >> funcallable instance inside the actual function attached to that >> instance. Am I doing something illgal here or is this a bug? > > It's a bug, I'm afraid. SBCL's calling convention for > funcallable-instances is different from that for ordinary functions, > so all sorts of things go haywire in the above case. As a > non-portable workaround, you can use sb-kernel:instance-lambda instead > of cl:lambda, above. In my experience, it also helps to create a function that doesn't close over anything. If you need to get values from the lexical environment, you can use the following trick: (sb-mop:set-funcallable-instance-function fn (compile nil `(lambda (x) (format t "Calling ~A with ~A. also ~A~%" ,fn x ,n)))) This doesn't give you the bindings, but may be good enough in many cases. Pascal -- 2nd European Lisp and Scheme Workshop July 26 - Glasgow, Scotland - co-located with ECOOP 2005 http://lisp-ecoop05.bknr.net/ |