[Cython] New function (pointer) syntax.

[Stefan Behnel]

Robert Bradshaw schrieb am 06.11.2014 um 19:56:
> On Thu, Nov 6, 2014 at 9:59 AM, Stefan Behnel wrote:
>> Robert Bradshaw schrieb am 06.11.2014 um 18:15:
>>> This becomes especially clear for return types, e.g.
>>>
>>>     cdef ((float -> float, float, float) -> float)
>>> get_integrator(char* algorithm):
>>>         if algorithm == ...
>>>
>>> vs
>>>
>>>     cdef float (*get_integrator(char* algorithm))(float (*)(float),
>>> float, float):
>>>         if algorithm == ...
>>
>> Same thing as above. The nesting is clearer in the latter.
> 
> Clearly we think differently... I can pick apart the latter
> definition, but I have to admit it took a lot longer to type than the
> former, and I still see "cdef float blah(...., float, float): ..."
> when in fact I'm declaring something that takes a char* (or should
> that read, "takes something that dereferences to a char" :-)).

I already said that C function types have their own quirks - I keep writing
(func*) instead of (*func), for example. It feels just arbitrary and fails
to stick in my head. But "->" is too well known as an operator when it
comes to pointers (which function types are in C) to provide for a *more*
readable alternative. Just because some functional languages use it in some
specific way doesn't mean it fits into a language that mixes Python and C.


> I am curious, when you read "cdef int * p" do you parse this as "cdef
> (int*) p" or "cdef int (*p)"

Definitely the former. And the complexity that some type declarations can
take in C (let alone C++) is just devastating.

Problem is, any new syntax in Cython will have to co-exist with the
existing (C) syntax potentially forever, and will add to the language
learning curve. People will learn one syntax, but have to understand the
second syntax in order to read other people's code. And others will start
adopting the new syntax in code that uses the old syntax without cleaning
up first.

If we go that route of adding yet another syntax, it needs to be an obvious
one from both a "C with Python features and syntax" and a "Python with C
datatypes" point of view. In short, it has to fit into the existing
language mix.

Stefan