As it turns out, it chose the wrong method to print the funcallable-standard-object: r14455.

Bye,

Erik.

On Tue, Apr 2, 2013 at 9:44 PM, Rudolf Schlatte rudi@constantly.at wrote:

On Apr 2, 2013, at 21:40, Erik Huelsmann ehuels@gmail.com wrote:

...

Well, to some extent I can see your problem. Indeed there seem to be no slots in the 'MOP:FUNCALLABLE-STANDARD-OBJECT class. The layoutFuncallableStandardClass is what confused me, but that's indeed the layout of the metaclass.

So, you're correct that the fix works by accident. The solution should be to add a slot by the name 'MOP::NAME to the FUNCALLABLE-STANDARD-OBJECT. That slot can contain the name of the object (ie function) for which the item is defined. In that case, we should probably remove the direct slot MOP::NAME on the standard generic function, since it's already defined on the superclass if we decide to do that.

While studying this problem using DESCRIBE, it seems our current implementation dispatches (DESCRIBE (MAKE-INSTANCE 'CL-CONT::FUNCALLABLE/CC)) the wrong way: to the T way instead of the STANDARD-OBJECT way...

Yet more to investigate...

For this general kind of problem, I'm currently partial to using Lisp-side operators + calling Lisp functions instead of using instanceof / Java-side cast + method call. E.g., FuncallableStandardObject.java:202:

    if (Symbol.SUBTYPEP.execute(arg,

StandardClass.STANDARD_GENERIC_FUNCTION) != NIL) { return new StandardGenericFunction((Layout)l); } else { return new FuncallableStandardObject((Layout)l); }

(The condition was "instanceof StandardGenericFunction" until recently). This seems more robust, and hopefully prepares us for transferring stuff Lisp-side eventually.

Rudi