On Thu, Oct 3, 2013 at 7:13 AM, Nathaniel Smith <n...@pobox.com> wrote:
> On Thu, Oct 3, 2013 at 3:00 PM, Stefan Behnel <stefan...@behnel.de> wrote:
>> Nathaniel Smith, 03.10.2013 14:35:
>>> On Thu, Oct 3, 2013 at 1:23 PM, Stefan Behnel wrote:
>>>> Greg Ewing, 03.10.2013 14:10:
>>>>> Robert Bradshaw wrote:
>>>>>> cdef int *a, b, c, *d[3]
>>>>>>
>>>>>> is IMHO quite ugly but also adds a lot of complexity to the parser.
>>>>>> What if instead we required
>>>>>>
>>>>>> cdef int* a
>>>>>> cdef int b, c
>>>>>> cdef int[3]* d
>>>>
>>>> The last line looks ambiguous, BTW, hadn't even noticed it before. Is that
>>>> an array of int pointers or a pointer to an array (pointer)? We should make
>>>> sure the way this is declared is really obvious and not unexpected to C
>>>> users.
>>> [...]
>>> The two halves of this email seem to sort of contradict each other,
>>> don't you think? At least the C syntax has the advantage that it's
>>> well-defined and many people *do* know it (and if they don't then
>>> there are bazillions of references around, plus you can just copy it
>>> out of header files if you're wrapping a C library), whereas as noted
>>> above, in fact there are *no* people who know how to look at int[3]*
>>> and be confident about what it means, even you...?
>>
>> Well, it's still better than looking at "*d[3]", now, isn't it? Maybe I'm
>> just confused (by both, actually) because I'm not really breathing C.
>
> Yeah, personally in either case I'd have to look it up (and it's
> simply impossible that you're going to make it as easy to lookup this
> funky Cython-specific syntax as it is to look up standard C syntax).
> But also, the reason I don't know the C version already is that I've
> probably never seen such a declaration in real life, which makes it
> hard to see why this is a really pressing problem.
Cause or effect :).
> I don't really come
> to Cython because I want idiosyncratic tweaks to things C already does
> perfectly well, you know?
I wouldn't classify this as something that "C already does perfectly
well." The fact that people commonly write
int* ptr;
rather than
int *ptr;
means that it's parsed differently in people's heads than the grammar,
and though it's hard to miss given the context of this thread I've
seen people gloss right over things like
char* a, b;
a = malloc(n);
b = malloc(n);
strcpy(b, a);
which, yes, is perfectly valid C (though any sane compiler will throw
out a warning). It should also be noted that an increasing percentage
of Cython users don't know C at all.
The rule would be very simple--type decorations would be left
associative, so an int*[5]** would be a pointer to a pointer to an
array of pointers to ints. Now, you're right that this doesn't come up
often, which is why it'll be easy to change, but it does complicate
the compiler (and hypothetical grammar). Ideally people shouldn't be
copying C headers in the long run, they should be parsed automatically
or by wrappers like xdress.
This would affect all variable declarations. E.g.
cdef int *foo(int* a[3], int (*b)[3]): ...
would become
cdef int* foo(int*[3] a, int[3]* b): ...
or
cdef int* foo(a : int*[3], b : int[3]*): ...
or even
cdef foo(a : int*[3], b : int[3]*) -> int*: ...
(those last two being rather hypothetical) and
ctypedef double point[3]
would become
ctypedef double[3] point
Function pointers are a bit harder, but
cdef double (*f)(int, long)
could become
cdef double (*)(int, long) f
unless we wanted to introduce something totally new like
cdef (int, long) -> double f
following Python return value annotation syntax (which is new, but
quite transparent in meaning).
- Robert
_______________________________________________
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel
