[Cython] Declaration syntax change

[Nathaniel Smith]

On Thu, Oct 3, 2013 at 5:03 PM, Robert Bradshaw <robertwb at gmail.com> wrote:
> On Thu, Oct 3, 2013 at 7:13 AM, Nathaniel Smith <njs at pobox.com> wrote:
>> On Thu, Oct 3, 2013 at 3:00 PM, Stefan Behnel <stefan_ml at 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.

So, like I said upthread, if this is the problem you're really trying
to solve, just tackle it directly by making 'char *a, b' an error of
some kind.

> 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.

That's a simple rule, but not necessarily a memorable one -- it's
exactly the opposite of how both English and C work. English: you'd
say "array of pointers" but write pointer-array *[]. C: *const * is a
const-pointer-to-pointer, but here it would be a
pointer-to-const-pointer.

In real life of course I'd parenthesize an expression like this to
make it unambiguous even for readers who don't remember the
precedence/associativity rules, but I guess in this notation you can't
parenthesize things, readers will have to memorize/look-up the
associativity regardless.

> 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.

But we don't live in the long run. Maybe that will happen eventually,
maybe it won't -- it's hard to make predictions, especially about the
future...

-n