On Thu, Oct 3, 2013 at 10:21 AM, Nathaniel Smith <n...@pobox.com> wrote: > 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.
Actually, this is like English. "Int pointer" or "int array pointer" where the preceding words describe the kind of pointer you have. (it can be inverted of course, key board = board of keys, stack pointer = pointer to the stack, etc.) Const is a pain, but I'd say it binds tighter than anything else and cannot be mixed with the other declarators to follow C conventions. E.g. "const int*" points to a const int, and "const (int*)" points to an int but can't be changed. > 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. Yes, write (((int*)[5])*)* will be supported, just as one can write (((a - b) - c) - c) instead of a - b - c - d. >> 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... Maybe this'll be additional motivation :). But as has been mentioned they don't come up often in real life, but do have an oversized presence in the compiler/grammar. Whatever script is provided to clean up existing .pxd files could be used to transform copy-pasted header declarations. - Robert _______________________________________________ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
