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

[Alex Martelli]

"Makhno" <mak at imakhno.freeserve.co.uk> wrote in message
news:8t1964$v8a$1 at news7.svr.pol.co.uk...
> >Even from a human-factors point of view, such syntactic
> >tripwires (over which people DO keep stumbling...) as
> >    if(a=0) ...       /* oops, an assignment...! */
>
> Most compilers warn at this point and make you write if ((a=0)) ...

"Many", yes; dunno 'bout "most" (VC++, for example, doesn't,
at usable warning-levels).  It's a sad reflection on C's
syntax that many compilers _have_ to warn against a perfectly
correct and very idiomatic form because it's SO error-prone;
the funny syntax with double parentheses, which gcc likes
(not many other compilers, I think), is not what C requires
(the extra parentheses are totally redundant here *in C*...).


> >    foo* bar, baz;    /* NOT two pointers... */
>
> I prefer to write my pointer declarations like this
>
> foo *bar;

Sure, it's better to write declarations in forms that
work, rather than in forms that don't!  But the point
is: this is not C syntax.  In C, it's just as valid
to place spaces on either or both or neither side of
that star -- it makes absolutely no difference.  The
above example line, trying (but failing) to declare
two pointers, is broken just the same.


> >    struct foo {
> >        int bar;
> >    }    /* forgot a semicolon... */
> >    /* int can be omitted and is implied -- how CRAZY! */
> >    myfun() ...
>
> Are you complaining about the implicit 'int' for function, or that if you
> forget the semicolon after the struct declaration and then try to declare
> the function afterwards the compiler will assume the the function returns
> the struct? Implicit 'int' functions are old anyway, modern compilers
should
> warn.

I'm complaining about a few of the many terrible design decisions
in C's syntax, which make it a travesty to call it "pretty good".
It's difficult to find worse-designed syntaxes than C's among
reasonably widespread languages.

That compilers "should" warn against perfectly valid syntax use
says it all.  How can you at the same time claim that a syntax
is "pretty good" and yet a compiler should NOT let you use it?!
How self-contradictory can you get?


> >hardly combine to make C's syntax "pretty good".  TERRIBLE
> >is more like it.
>
> Oh please calm down. C's syntax has something to do with its success eg:
Not
> having to write code at the speed of the slowest person. I personally
don't

C's syntax has many redundancies compared to one optimally
designed for the purpose you imply.  Just look at Python's
by comparison!


> care if some newbie writes 'if (a=0)...' when they mean 'if (a==0)'
because
> I don't. Anyway, they should be writing 'if (!a) ...'
> I like being able to compress less-important mundane error checking code
> into a couple of lines, saving the long winded approach to more
complicated
> parts, where readability is important.

That has nothing to do with C's terrible syntax.  Error handling is
a weak part of C anyway, but basically because of semantic-level (no
exception-handling), and the syntax has got nothing to do with it.

C's success came from being there at the right time with a language
at the right level -- high-level enough to offer substantial extras
in productivity and portability wrt structured-assemblers, low-level
enough to be ideal for system-code, or application-code on machines
too slow and limited to support much more.  The horrid syntax was
not horrid enough to stop that (good programmers will privilege many
other considerations far above syntax-issues in choosing a language;
most people with syntax-fixation won't be the decision-makers and
opinion-leaders in their peer groups).


> >:-)
>
> phew. A smiley. Was worried for a moment that you were serious.

I'm perfectly serious in considering C a horrible example of syntax,
and believing that nobody who understands the issue will differ --
somebody who claims the syntax is pretty good AND in the same
breath claims a compiler "should" warn against using it clearly
not counting as "understanding".  The smiley was specifically about
equating appreciation for C's syntax to the Stockholm Syndrome.


Alex