Fwd: Making every goops object applicable

[Krister Svanlund <krister.svanlund@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2909 bytes --]

---------- Forwarded message ----------
From: Krister Svanlund <krister.svanlund@gmail.com>
Date: Tue, May 15, 2012 at 2:45 AM
Subject: Re: Making every goops object applicable
To: Mark H Weaver <mhw@netris.org>


On Tue, May 15, 2012 at 12:16 AM, Mark H Weaver <mhw@netris.org> wrote:

> Krister Svanlund <krister.svanlund@gmail.com> writes:
> > In our work to look into how Python 3 could be implemented for Guile
> > we have figured out that the only way to make a goops object
> > applicable is to have it inherit <applicable-struct>. This does not
> > always work the way it could be expected, for example when inheriting
> > from several classes.
>
> Can you elaborate on what doesn't work as expected?
>

For example an instance of a class inheriting a class that inherits
<applicable-struct> that defines 'procedure is not applicable.


>
> > Apparently this works by some flag being set by
> > <applicable-strukt> in libguile for the object and that flag is
> > checked during application, calling the 'procedure slot if it's set
> > with some optimization assuming that 'procedure is the first slot.
> > Is this correct and if so, is there any particular reasoning behind
> > this rather than just having all classes that has the slot 'procedure
> > be applicable?
>
> I see at least two problems with your suggestion: (1) it would be very
> slow to search the list of slots for a slot named 'procedure' on every
> application.  (2) a user might create a class with a slot named
> 'procedure' without intending that the slot should be used in this way.
>

(1) Given that slots aren't dynamic at runtime (as they are in Python for
example) and there is already some magic being done by <applicable-struct>
I have a hard time seeing how looking up a slot for application can't be
done in almost constant time (one look-up and then storing a pointer to the
position of the slot for future applications) and only a tiny bit slower
than the current implementation. And after all, Guile is, judging by it's
documentation, focused on being an extension language where the heavy
lifting is supposed to be done in C code.
(2) This I'm not entirely sure how to fix but I have the impression that
this could be done analogous to the initialization method of the
meta-object protocol, but I assume this could require some severe internal
changes and in fact slow down applications in general in Guile. My thought
is that you simply have a metaclass that has a method ('apply or similar)
that specifies what will happen if an instance of any of it's classes is
being used as a function.

I'm mostly interested in getting all possible input about how good/bad of
an idea this is so please prove (in the looses sense of the word) that I'm
wrong. When I have some free time this summer I will probably make an
attempt at doing this anyhow, I just want to know what I'm getting myself
into.

Yours,
Krister Svanlund

[-- Attachment #2: Type: text/html, Size: 3942 bytes --]