On May 23, 2008, at 9:56 AM, Dag Sverre Seljebotn wrote: > 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.
+1 I think we're to this point. > 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.) Perhaps put an example of a __getitem__ method that uses this feature. It seems mostly this could be handled with plain old function overloading, but this would be a nice feature to have in and of itself. > > 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 _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
