[Cython] Fused Types

[Robert Bradshaw]

On Mon, May 2, 2011 at 1:56 PM, mark florisson
<markflorisson88 at gmail.com> wrote:
> On 2 May 2011 18:24, Robert Bradshaw <robertwb at math.washington.edu> wrote:
>> On Sun, May 1, 2011 at 2:38 AM, mark florisson
>> <markflorisson88 at gmail.com> wrote:
>>> A remaining issue which I'm not quite certain about is the
>>> specialization through subscripts, e.g. func[double]. How should this
>>> work from Python space (assuming cpdef functions)? Would we want to
>>> pass in cython.double etc? Because it would only work for builtin
>>> types, so what about types that aren't exposed to Python but can still
>>> be coerced to and from Python? Perhaps it would be better to pass in
>>> strings instead. I also think e.g. "int *" reads better than
>>> cython.pointer(cython.int).
>>
>> That's whey we offer cython.p_int. On that note, we should support
>> cython.astype("int *") or something like that. Generally, I don't like
>> encoding semantic information in strings.
>>
>> OTHO, since it'll be a mapping of some sort, there's no reason we
>> can't support both. Most of the time it should dispatch (at runtime or
>> compile time) based on the type of the arguments.
>
> If we have an argument type that is composed of a fused type, would be
> want the indexing to specify the composed type or the fused type? e.g.
>
> ctypedef floating *floating_p

How should we support this? It's clear in this case, but only because
you chose good names. Another option would be to require
parameterization floating_p, with floating_p[floating] the
"as-yet-unparameterized" version. Explicit but redundant. (The same
applies to struct as classes as well as typedefs.) On the other had,
the above is very succinct and clear in context, so I'm leaning
towards it. Thoughts?

> cdef func(floating_p x):
>    ...
>
> Then do we want
>
>    func[double](10.0)
>
> or
>
>    func[double_p](10.0)
>
> to specialize func?

The latter.

> FYI, the type checking works like 'double_p is
> floating_p' and not 'double is floating_p'. But for functions this is
> a little different. On the one hand specifying the full types
> (double_p) makes sense as you're kind of specifying a signature, but
> on the other hand you're specializing fused types and you don't care
> how they are composed -- especially if they occur multiple times with
> different composition. So I'm thinking we want 'func[double]'.

That's what I'm thinking too. The type you're branching on is
floating, and withing that block you can declare variables as
floating*, ndarray[dtype=floating], etc.

- Robert