[Cython] CEP1000: Native dispatch through callables

[Dag Sverre Seljebotn]

On 04/15/2012 09:30 AM, Stefan Behnel wrote:
> Dag Sverre Seljebotn, 15.04.2012 08:58:
>> Ah, Cython objects. Didn't think of that. More below.
>>
>> On 04/14/2012 11:02 PM, Stefan Behnel wrote:
>>> thanks for writing this up. Comments inline as I read through it.
>>>
>>> Dag Sverre Seljebotn, 14.04.2012 21:08:
>>>> each described by a function pointer and a signature specification
>>>> string, such as "id)i" for {{{int f(int, double)}}}.
>>>
>>> How do we deal with object argument types? Do we care on the caller side?
>>> Functions might have alternative signatures that differ in the type of
>>> their object parameters. Or should we handle this inside of the caller and
>>> expect that it's something like a fused function with internal dispatch in
>>> that case?
>>>
>>> Personally, I think there is not enough to gain from object parameters that
>>> we should handle it on the caller side. The callee can dispatch those if
>>> necessary.
>>>
>>> What about signatures that require an object when we have a C typed value?
>>>
>>> What about signatures that require a C typed argument when we have an
>>> arbitrary object value in our call parameters?
>>>
>>> We should also strip the "self" argument from the parameter list of
>>> methods. That's handled by the attribute lookup before even getting at the
>>> callable.
>>
>> On 04/15/2012 07:59 AM, Robert Bradshaw wrote:
>>> It would certainly be useful to have special syntax for memory views
>>> (after nailing down a well-defined ABI for them) and builtin types.
>>> Being able to declare something as taking a
>>> "sage.rings.integer.Integer" could also prove useful, but could result
>>> in long (and prefix-sharing) signatures, favoring the
>>> runtime-allocated ids.
>>
>> I do think describing Cython objects in this cross-tool CEP would work
>> nicely, this is for standardized ABIs only (we can't do memoryviews either
>> until their ABI is standard).
>
> It just occurred to me that an object's type can safely be represented at
> runtime as a pointer, i.e. an integer. Even if the type is heap allocated
> and replaced by another one later, a signature that uses that pointer value
> in its encoding would only ever match if both sides talk about the same
> type at call time (because at least one of them would hold a life reference
> to the type in order to actually use it).

The missing piece here is that both me and Robert are huge fans of 
Go-style polymorphism. If you haven't read up on that I highly recommend 
it, basic idea is if you agree on method names and their signatures, you 
don't have to have access to the same interface declaration (you don't 
have to call the interface the same thing).

Guess we should let this rest for a few days and get back to it with 
some benchmarks; since all we need to solve in CEP1000 is interned vs. 
strcmp. I'll try to do that.

Dag