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
_______________________________________________
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
