[armedbear-devel] Other findings (was Re: Questions about r14452 (Fix cl-cont))

[Erik Huelsmann]

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 at constantly.at> wrote:

>
> On Apr 2, 2013, at 21:40, Erik Huelsmann <ehuels at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20130402/df7f8579/attachment.html>