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