On Thu, Oct 3, 2013 at 5:03 PM, Robert Bradshaw <rober...@gmail.com> wrote: > 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.
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 _______________________________________________ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel