[Cython] Declaration syntax change

[Robert Bradshaw]

On Thu, Oct 3, 2013 at 9:30 AM, Chuck Blake <cb at mit.edu> wrote:
> Greg Ewing wrote:
>>What would be the benefit of this? You're proposing to change
>>from something identical to C declaration syntax, which is
>>second nature for a great many people, to something that
>>looks deceptively like C syntax but isn't.
>>
>>I can't see that causing anything other than a massive
>>amount of confusion, anguish and hair-tearing.
>
> I would echo this, actually.

The big win is a simplification of the grammar (and its diff to the
Python grammar), both for humans and for the computer. Just being able
to write an actual grammar for Cython would be nice--there's too much
special casing/logic in the parser right now.

> While the C declarator syntax takes
> a while to get used to, there is actually a simple rationale for
> why it is the way it is: just one set of operator associativity
> and precedences.  The way [], *, and function call ()s bind do
> not vary by context.  One doesn't have to remember multiple sets
> of rules "tailored" for various contexts like declaration/typedef
> definition or casting vs operator application.

I don't think this proposal would require multiple sets of rules for
different contexts.

> I believe this is the "fact underlying" the reactions various folk
> here are having of "initially seemingly clearer, but oh wait..what
> about corner case?"  There is a simplicity embedded in the seemingly
> backwards "operators you need to apply to get the base type" rule.

While I understand the reasoning and construction of C type
declarators, I don't think it makes for clear code. Note that
Cython/Pyrex does not have the deference operator which is by far the
most common declarator annotation, so this makes even less sense than
in C.

Of course trying to find/flesh out any forgotten corner cases is a big
point of this thread. Function pointers still need to be resolved.

> The manual translation of C headers/decls to Cython is another good
> point.  I think that it's a big departure from the perhaps hard to
> articulate "sweet spot" Cython/Pyrex are trying to hit straddling
> the C & Python worlds.
>
>
> Stefan Behnel wrote:
>>Also, C is only second nature to some people. A great many people actually
>>use Cython specifically to *avoid* having to write C.
>
> This is a fair point, but Pyrex/Cython have a decade plus long
> history here of being very close to C in this specific way,
> which is kind of a central thing..almost like a different way
> to spell the same type grammar.  It's easy after a short while
> to visually see the translation.  With whole new syntax and maybe
> parens in new, shiner places, I doubt seeing the mapping would be
> so easy for "hard cases".  And easy cases are easy.
>
>
> On a separate relase-number-tying note, I also feel like the
> Cython 1.0 target (or even Pyrex 1.0) was always more about
> compatibility with "whatever Python you throw at the Cython
> compiler" than about finality to all the various extended
> Cython syntax areas.  There are quite a few beyond-Py syntax
> areas at this point.

Yes, it still is. But it would be nice to get any such major changes
out of the way ahead of time.

> So, *if* the conclusion is that there is a group will and solid
> rationale to let Cython allow a user to use an *alternate* type
> declaration sub-language/warnings/a wrapper/macro syntax, then I
> don't see any 1.0-release relevance.  Cython grows just yet another
> way to specify the same things at whatever rev is easy.  The 1.0
> only matters if it's a strict backward incompatible proposal,
> but I sense a bit of discord on this response chain about that.
> Maybe changing "cdef" to be "cydef" would be a visual flag that
> an entirely different syntax is afoot?  But then..sooo many ways
> to specify types.

That doesn't help with the goal of simplifying the language.

> If you really want to be *that* different - arguably almost as
> much as different as simply requiring Python3 and annotations
> rather than having "cdef" at all, then why not go all the way
> and full on require Py3?  Then a user confronts all the Py3 core
> syntax change and Cy2.0 (or maybe Cy1.5 as 3.0/2 or whatever)
> at the same time.  And, why, the changes are even related to
> only-in-Py3 things to boot.  Just my two cents, anyway.

Python2 isn't dead yet. Also, I think changes are more easily done
one-at-a-time, and this would be an easier transition as it's a purely
syntactic (not semantic) change that could be done safely
automatically. In fact, if we dissallow "cdef int* a, b" I think
there's syntax that's interpreted differently.

- Robert