[Cython] Fused Types

Dag Sverre Seljebotn d.s.seljebotn at astro.uio.no
Mon May 2 15:15:33 CEST 2011


On 05/02/2011 03:00 PM, Sturla Molden wrote:
> Den 02.05.2011 11:15, skrev Dag Sverre Seljebotn:
>>
>> I.e., your question is very vague.
>
> Ok, what I wanted to ask was "why have one syntax for interfacing C++
> templates and another for generics?" It seems like syntax bloat to me.
>
>
>> You're welcome to draft your own proposal for full-blown templates in
>> Cython, if that is what you mean. When we came up with this idea, we
>> felt that bringing the full power of C++ templates (including pattern
>> matching etc.) into Cython would be a bit too much; I think Cython
>> devs are above average sceptical to C++ and the mixed blessings of
>> templates.
>>
>> E.g., one reason for not wanting to do it the C++ way is the need to
>> stick largs parts of your program in header files. With fused types,
>> the valid instantiations are determined up front.
>
> C++ templates are evil. They require huge header files (compiler
> dependent, but they all do) and make debugging a night mare. Template
> metaprogramming in C++ is crazy; we have optimizing compilers for
> avoiding that. Java and C# has a simpler form of generics, but even that
> can be too general.
>
> Java and C# can specialize code at run-time, because there is a
> JIT-compiler. Cython must do this in advance, for which fused_types
> which will give us a combinatoral bloat of specialized code. That is why
> I suggested using run-time type information from test runs to select
> those we want.

Well, I think that what you see about "fused_types(object, list)" is 
mainly theoretical exercises at this point.

When fused_types was discussed originally the focus was very much on 
just finding something that would allow people to specialise for 
"float,double", or real and complex.

IOW, the kind of specializations people would have generated themselves 
using a templating language anyway.

Myself I see typing from profile-assisted compilation as a completely 
seperate feature (and something that's internal to "cython 
optimization"), even though they may share most implementation details, 
and fused types makes such things easier (but so would C++-style 
templates have done).

> Personally I solve this by "writing code that writes code". It is easy
> to use a Python script to generate ad print specialized C or Cython code.

fused_types is simply a proposal to make people resort to this a little 
less often (not everybody are comfortable generating source code -- I 
think everybody reading cython-devel are though). Basically: We don't 
want C++ templates, but can we extend the language in a way that deals 
with the most common situations. And fused_types was the compromise we 
ended up with.

DS


More information about the cython-devel mailing list