C's syntax (was Re: Python Formatted C Converter (PfCC))

[Alex Martelli]

"Erik Max Francis" <max at alcyone.com> wrote in message
news:39F45AF5.E7387466 at alcyone.com...
    [snip]
> >     foo * bar;
>
> That's just the way the language works.  It's neither good nor bad.

Having to "go non-local" to even _parse_ some code IS inherently
bad.  Why should the syntax tree change drastically depending on
what is or isn't typedef's in some system headers...?!

> It's certainly not ambiguous and confusing unless you _try_ to write
> pathological code.

If this happens to be the last declaration/first statement
in a block (in C89; dunno if C99 admits declarations among
statements), and you're trying to locally declare bar as a
pointer to type foo, this will cause a silent error (by
language syntax rules; no doubt the "any reasonable compiler
will warn" argument will be used again?-) if foo, rather
than naming a type, names a global numeric variable (and
so does bar).

You may consider using global variables "pathological code",
but it's still a rather widespread practice, you know.  The
allegedly "pretty good syntax" of C admits overriding names
in nested blocks, so this could happen even with no global
variables involved (although the 'locality' in this case
might make diagnosis less of a horror).


> > Even from a human-factors point of view, such syntactic
> > tripwires (over which people DO keep stumbling...) as
> >     if(a=0) ...       /* oops, an assignment...! */
>
> Any reasonable compiler will warn about this.

Any reasonable language syntax would forego the need for
such warnings.

If you program in the language-syntax defined by "that
subset of C which my favourite compilers will accept
without warnings", then it's not C's syntax that you
are using, but, rather, that specific subset.  The
subsetting is, no doubt, a good idea, to reduce a
bit the horrors of C syntax.  But the need for it
militates _against_ the assertion that said syntax
is "pretty good".


> > or
> >     foo* bar, baz;    /* NOT two pointers... */
>
> That's a programmer error.  In declaring pointers, the * is a declarator
> and binds to the variable, not the type.  That's why coding styles such

Yes, it's a programmer error (as are the other programmer
errors I was exemplifying here), aided and abetted by crazy
language syntax.

Why aren't you claiming that any reasonable compiler should
warn against the crazy practice of declaring, _in a single
declaration_, some foo's, some pointers to foo's, some
arrays of foo's, some functions returning foo's, ...?  Just
because your favourite C compilers happen to be unreasonable
on this issue?-)

> as writing `int* p' end up only causing problems, because they imply
> that the * binds to the type when it does not.

Ah, shouldn't any reasonable compiler warn against them, then?-)


> >     struct foo {
> >         int bar;
> >     }    /* forgot a semicolon... */
>
> So what?

So the compiler will take this as the returntype for the
following function.

> >     /* int can be omitted and is implied -- how CRAZY! */
>
> Not in C99.

So you admit that the C syntax that has been defined in
de-facto and de-jure standards for almost 30 years _IS_
crazy, and only claim "pretty good" status for the syntax
of a newer language version -- a version that, AFAIK, is
not the one currently implemented by widespread C compilers
such as gcc, Microsoft Visual C++, Borland C++, ...?

I'm glad that C99 has finally adopted C++'s innovation
of forbidding implicit-int.  This does reduce the horror
of C's syntax (maybe in 10 years, C99 will be widespread
enough that this will actually make a difference:-).

Depending on what good and bad syntax ideas C99 has chosen
to take from other C-derived syntaxes (Java's prohibition
against inner-blocks declaring names that hide those
defined in outer-blocks, C++'s ability to mix declarations
and statements, C++'s oldish alternate typename(expression)
syntax for casts [that counts as a _bad_ syntax idea:-)]...),
the cosmetic surgery can be minor or major.  I'm sure it
will never be as major as to raise the syntax of C and
its derivatives to the exhalted status of "pretty good",
though... that would take _too_ much changing.


Alex