On Thu, Nov 6, 2014 at 11:56 AM, Stefan Behnel <stefan...@behnel.de> wrote:
> 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.
Even Java8 is adopting this token for lambdas, though I have to admit
my bias probably comes at least partially from mathematics (where I
write "let f: Z -> Z be a map from the integers to itself")... and I
was happy that
def foo(a: x, b: y) -> z: ...
simplified nicely down to
(x, y) -> z
but I see your point that this is much more foreign coming from the C
side of things.
>> 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.
I wouldn't say forever. Yes, this sounds a bit like Python 2 vs. 3,
but we could provide a tool to do the conversion (completely correctly
in this case) and as developers often run Cython themselves and ship
the .c files it should be a much less painful transition.
> 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.
+1. I hope to get more than two pairs of eyeballs on the issue.
- Robert
_______________________________________________
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel
