[Cython] template types

[Dag Sverre Seljebotn]

Stefan Behnel wrote:
> Dag Sverre Seljebotn wrote:
>> Before the C++ syntax sticks
> 
> I actually think it makes sense. In declarations, the parameter can appear

Well it certainly has the advantage that C++ and Java knows what it 
means right away.

> only behind type names, so parsing them would be trivial - except for
> cases where the type name appears in an expression:
> 
>     isinstance(x, MyType<int>)
>     type_ref = MyType<int>  vs.  type_ref = SomeValue < something > 5

In general, foo<bar>(baz) can mean two things, and you don't know until 
you know what kind of expression foo is.

This makes it virtually guaranteed that if Python gets generic 
interfaces somehow [1] this will not be the syntax of choice, as Guido 
hates these kinds of things even if it is technically possible to 
seperate it, possible to require that you write a<(b>a) or similar.

Also in Python (and in Cython with metaprogramming/macro support!), one 
could envisage doing

def f():
   if wierd: return FooTemplate
   else: return BarTemplate

f()<bar>(baz)
# operators or template instantiation? won't know 'till runtime

[1] Well, I suppose 3rd party libraries can already add interfaces, 
including templated ones, using metaclasses

> Not sure if
> 
>     type_ref = MyType[int]
> 
> makes this any simpler - it may at least simplify the parser, although
> there might be further ambiguities with buffers, array sizes and indexing.

Well, there's already ambiguities here (and still a regression compared 
to before I mixed things up with buffers) making the current parser 
approach suboptimal. One day when I get time I think I'll just introduce 
BracketOperatorNode, and leave deciding what it does to later transforms.

One thing I really dislike in current Cython code is that the parser has 
to know whether things are types or not in a given context. (Although I 
think Robert fixed at least some of this.)

BTW one can look at a template as a collection of types, and template 
instantiation as fetching the right type in the collection.

> I also considered keyword arguments to the type (like Py3's "metaclass"),
> but didn't find an obvious way to keep that information in the type name
> when referring to it later on.
> 
>     cdef class MyType(SomeParent, templates=[T,V]):
>         ...
> 
>     cdef MyType(T=int, V=list) my_instance
>     my_instance = MyType(1,2,3,4, T=int, V=list)
> 
> ... does that look readable?

Hmm. It's an alternative to consider although I must admit my guts 
prefer MyType<T, V> to this.

> That's sick. Looks like a scanner problem, though, not a parser problem.
> The parser would know that '>>' doesn't make any sense at all at that
> position (ok, it's C++, but let's assume a sane kind of 'sense' here).

Well it is the same kind of problem as above; basically you don't know 
whether

a<b<c>> d;

is doing arithmetic or instantiating a variable until you can fully 
resolve what kind of identifiers a, b, c and d are. Just makes 
everything more complicated, and it is harder to parse for humans as well.

The difference with a[b](c) is that you at least know how to structure 
the parse tree and the operator precedence just by looking at it without 
knowing anything about a, b and c.



-- 
Dag Sverre