From: ······@gmail.com
Subject: SBCL funcallable-standard-class confusion
Date: 
Message-ID: <1119928079.952309.8790@z14g2000cwz.googlegroups.com>
I am having some problems related to SBCL's funcallable-standard-class
that I'm hoping someone can help me sort out.

test.lisp:
-------------------------------
(defclass fn ()
  ()
  (:metaclass sb-mop:funcallable-standard-class))

(defmethod initialize-instance :after ((fn fn) &rest initargs &key
&allow-other-keys)
  (declare (ignore initargs))
  (format t "Initializing ~A...~%" fn)
  (sb-mop:set-funcallable-instance-function fn
                                            (lambda (x)
                                              (format t "Calling ~A
with ~A.~%" fn x)))
  (format t "Initialized ~A.~%" fn))

(funcall (make-instance 'fn) 42)
-------------------------------

[······@Hiro:/Users/jtdubs]% sbcl
This is SBCL 0.9.0, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
* (load "test")
Initializing #<FN {4099EA55}>...
Initialized #<FN {4099EA55}>.
Calling #<CLOSURE (LAMBDA (X)) {4099F77D}> with 42.
T
*

Hey, cool, I've created a self-referencing anonymous function without
the Y-combinator!  ;-)

Google turned up a reference to this problem here:
http://www.caddr.com/macho/archives/sbcl-devel/2003-5/1927.html

That was from 2003.  It seems to be the same issue.  Any known
workarounds?  Any idea when this might be fixed?  Anything I can do to
help fix it?

Justin Dubs

From: ······@gmail.com
Subject: Re: SBCL funcallable-standard-class confusion
Date: 
Message-ID: <1119930817.159772.23530@g44g2000cwa.googlegroups.com>
······@gmail.com wrote:
> I am having some problems related to SBCL's funcallable-standard-class
> that I'm hoping someone can help me sort out.
>
> test.lisp:
> -------------------------------
> (defclass fn ()
>   ()
>   (:metaclass sb-mop:funcallable-standard-class))
>
> (defmethod initialize-instance :after ((fn fn) &rest initargs &key
> &allow-other-keys)
>   (declare (ignore initargs))
>   (format t "Initializing ~A...~%" fn)
>   (sb-mop:set-funcallable-instance-function fn
>                                             (lambda (x)
>                                               (format t "Calling ~A
> with ~A.~%" fn x)))
>   (format t "Initialized ~A.~%" fn))
>
> (funcall (make-instance 'fn) 42)
> -------------------------------
>
> [······@Hiro:/Users/jtdubs]% sbcl
> This is SBCL 0.9.0, an implementation of ANSI Common Lisp.
> More information about SBCL is available at <http://www.sbcl.org/>.
>
> SBCL is free software, provided as is, with absolutely no warranty.
> It is mostly in the public domain; some portions are provided under
> BSD-style licenses.  See the CREDITS and COPYING files in the
> distribution for more information.
> * (load "test")
> Initializing #<FN {4099EA55}>...
> Initialized #<FN {4099EA55}>.
> Calling #<CLOSURE (LAMBDA (X)) {4099F77D}> with 42.
> T
> *
>
> Hey, cool, I've created a self-referencing anonymous function without
> the Y-combinator!  ;-)
>
> Google turned up a reference to this problem here:
> http://www.caddr.com/macho/archives/sbcl-devel/2003-5/1927.html
>
> That was from 2003.  It seems to be the same issue.  Any known
> workarounds?  Any idea when this might be fixed?  Anything I can do to
> help fix it?

Okay, so changing the lamba to a sb-kernel:instance-lambda makes it
work as designed.  This was mentioned on the caddr.com link I posted
originally.  Don't know how I missed that the first time through...

Anyway, the original question remains as to why this doesn't work with
lambda.

Justin Dubs
From: Christophe Rhodes
Subject: Re: SBCL funcallable-standard-class confusion
Date: 
Message-ID: <sqll4vggnh.fsf@cam.ac.uk>
······@gmail.com writes:

> Anyway, the original question remains as to why this doesn't work with
> lambda.

Briefly: because the calling convention for
funcallable-standard-instances in the version of
PCL-the-CLOS-implementation present in SBCL is different from the
calling convention for normal functions.  As far as I'm concerned,
this is a bug.

Cheers,

Christophe