Seems that we will be able to reach some kind of consensus for an initial subset of my proposal?:
- The "name of the feature" will be parametric polymorphism. - Introduced through the "generic" type specifier in "cdef" functions only. - Such functions are not exportable across module boundaries (only same pyx, or as inline pxd functions) - Allow the "typeof" operator in variable declarations in function bodies to resolve the actual type of the generic. This should be forward-compatible to anything done with extending to def, extending to cross-module support, making "generic" the default argument "type" and so on. Such things can be dealt with and discussed when all the above is in place and stable. Agreed/not agreed? If agreed upon, I'll strip down the doc and make it a CEP. And then if Robert agree it's the way to go for my project, I'll implement this as part of my GSoC for the benefit of NumPy __getitem__ and __setitem__. (Given enough time of course.) Stefan wrote: > Hi, > > Dag Sverre Seljebotn wrote: >> Robert wrote: >>> cdef max(generic a, generic b): >>> return a if a >= b else b >>> >>> where "generic" is a special type. > > This is called "parametric polymorphism", a concept from ML and one of the > reasons why compiled ML code is so freaking fast. > > http://en.wikipedia.org/wiki/Polymorphism_(computer_science)#Parametric_polymorphism > Thanks, I'll use that term from now on. >> Yes, I really, really like this one. > > So do I. Very explicit. > > How would that map to C space? Would you have functions called > > ..._generic_int_float_max(int a, float b) > > ? What about extension types? Imagine a stupid type called "int_float" ... Well, obviously one would escape the _ character in type names if that was used as a seperator, but I know that's not the point here :-) I wrote some lines about that in my doc as well, "cross-module duckdefs". The cases are: 1) You know the implementation (same pyx or inline-code-in-pxd). In this case you can create your own instantiations, and you simply mangle them incrementally and keep record of them during the same Cython compilation process. "pyx_pp1_max", "pyx_pp2_max"... 2) You do not know the implementation. But then any instantiations must have been made when the module was compiled, one cannot make new ones, and a lot of the utility for them disappears. I'd be happy to just deny calling such functions across modules at first (and one can look at name mangling later and pre-instantiation later...or read the section in my doc). There is another option though (also outlined in my doc) involving replacing "generic" with "object" across module boundaries, so that only speed is impacted, but it requires a new, parallell type system for native types (making them coerce to Python objects that preserve overflow semantics). >> If "generic" is not clear enough, "auto" is another option. > > I prefer "generic". "auto" sounds more like "find the correct type > yourself" > and doesn't make it clear that this can lead to code duplication and > actually > works for multiple type candidates. Ok, you convinced me. >> This could be an argument for waiting with supporting explicit >> overloading >> until the time that Python decides to do so. > > Overloading and parametric polymorphism are orthogonal concepts. Both have > their niche. Intuitively, I would expect both to be similarly complex to > implement, but PP looks much more pythonic to me and can be done without > caring about Python compatibility, so I would propose to go for that one > first. Sounds good. Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
