[Cython] Fused Types

[Dag Sverre Seljebotn]

On 05/04/2011 08:13 PM, Robert Bradshaw wrote:
> On Wed, May 4, 2011 at 1:47 AM, mark florisson
> <markflorisson88 at gmail.com>  wrote:
>> On 4 May 2011 10:24, Dag Sverre Seljebotn<d.s.seljebotn at astro.uio.no>  wrote:
>>> On 05/04/2011 01:07 AM, Greg Ewing wrote:
>>>>
>>>> mark florisson wrote:
>>>>
>>>>> cdef func(floating x, floating y):
>>>>> ...
>>>>>
>>>>> you get a "float, float" version, and a "double, double" version, but
>>>>> not "float, double" or "double, float".
>>>>
>>>> It's hard to draw conclusions from this example because
>>>> it's degenerate. You don't really need multiple versions of a
>>>> function like that, because of float<->  double coercions.
>>>>
>>>> A more telling example might be
>>>>
>>>> cdef double dot_product(floating *u, floating *v, int length)
>>>>
>>>> By your current rules, this would give you one version that
>>>> takes two float vectors, and another that takes two double
>>>> vectors.
>>>>
>>>> But if you want to find the dot product of a float vector and
>>>> a double vector, you're out of luck.
>>>
>>> First, I'm open for your proposed syntax too...But in the interest of seeing
>>> how we got here:
>>>
>>> The argument to the above goes that you *should* be out of luck. For
>>> instance, talking about dot products, BLAS itself has float-float and
>>> double-double, but not float-double AFAIK.
>>>
>>> What you are saying that this does not have the full power of C++ templates.
>>> And the answer is that yes, this does not have the full power of C++
>>> templates.
>>>
>>> At the same time we discussed this, we also discussed better support for
>>> string-based templating languages (so that, e.g., compilation error messages
>>> could refer to the template file). The two are complementary.
>>>
>>> Going back to Greg's syntax: What I don't like is that it makes the simple
>>> unambiguous cases, where this would actually be used in real life, less
>>> readable.
>>>
>>> Would it be too complicated to have both? For instance;
>>>
>>>   i) You are allowed to use a *single* fused_type on a *function* without
>>> declaration.
>>>
>>> def f(floating x, floating *y): # ok
>>>
>>> Turns into
>>>
>>> def f[floating T](T x, T *y):
>>>
>>> This is NOT ok:
>>>
>>> def f(floating x, integral y):
>>> # ERROR: Please explicitly declare fused types inside []
>>>
>>>   ii) Using more than one fused type, or using it on a cdef class or struct,
>>> you need to use the [] declaration.
>>>
>>
>> I don't think it would be too complicated, but as you mention it's
>> probably not a very likely case, and if the user does need it, a new
>> (equivalent) fused type can be created. The current way reads a lot
>> nicer than the indexed one in my opinion. So I'd be fine with
>> implementing it, but I find the current way more elegant.
>
> I was actually thinking of exactly the same thing--supporting syntax
> (i) for the case of a single type parameter, but the drawback is the
> introduction of two distinct syntaxes for essentially the same
> feature. Something like this is necessary to give an ordering to the
> types for structs and classes, or when a fused type is used for
> intermediate results but not in the argument list. I really like the
> elegance of the (much more common) single-parameter variant.
>
> Another option is using the with syntax, which was also considered for
> supporting C++ templates.

In particular since that will work in pure Python mode. One thing I 
worry about with the func[]()-syntax is that it is not Python compatible.

That's one thing I like about the CEP, that in time we can do

def f(x: floating) -> floating:
     ...

and have something that's nice in both Python and Cython.

Dag Sverre