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

[Alex Martelli]

"Grant Griffin" <not.this at seebelow.org> wrote in message
news:39F5E620.C780A71C at seebelow.org...
    [snip]
> Sounds like you have the makings of a "Python Guru Available For
> Contract Work". <wink>

I might become one, should I ever become unhappy with my current
employer (or vice-versa:-).  Right now, the mission of bringing
"3D to everyone, everywhere" keeps our mutual enthusiasm as high
as it was over the last 12 years, so head-hunters need not apply.


> Just for curiosity, could you be a little more specific here?  Sure, C
> has its several known pitfalls.  But those aside, what's so bad about
> it's syntax overall?

Apart from its various defects (quirks and flaws, as Dennis Ritchie,
C's inventor, calls them), there's nothing much wrong with it.  (I
have yet to meet anything that -- aparts from pitfalls, defects,
quirks, flaws, etc -- has anything wrong with it... by definition
of flaws, quirks, and so on).


> Having written a lot of Pascal right before I learned C, I found C's
> syntax to be quite a relief.  Isn't nice to type "{" rather than
> "begin"?  (Or, better yet, to type nothing at all in Python?  <wink>)

I agree with you (and Guido) that not having to type any bogus
block/begin and block/end symbols is best.  If I did have to have
block-symbols, though, punctuation would not be my first choice
(too much punctuation, and you end up with Perl's C-inspired
syntax...).  My personal favourite style is that of having
specific end-words ("if condition: foo; bar; baz; fi"), despite
Harel's delicious satire in "'do considered od' considered
odder than 'do considered ob'" (which, I suspect, played a
role in killing this style -- it's now badly out of fashion).

But this is really the 'sugariest' of syntax issues.


> did Pascal ever need that bogus ":=" thing in the first place?
> <<designed by a guy who didn't use it much>>

I don't know why you think that Backus "didn't use much" the
assignment statement at the end of the '50s -- I think he
switched to functional programming only a good while later.

He had first introduced '=' for assignment (in Fortran, the
first language he invented, in 1954); contextually with his
contributions to the Algol committee, he also introduced
the '::=' notation for "is defined as" (as part of Backus
Normal Form); thus, I suspect he was also responsible for
the graphically-intermediate usage of ':=' in Algol (from
which many other languages, Pascal included, copied it).
I guess he might have learned something between 1954 and
1959, observing what happened with = as assignment...?-)

Fortran was the inspiration of PL/I to keep using = for
assignment; and PL/I was Ritchie's inspiration (in B, the
immediate predecessor to C) for changing BCPL's ':=' to '='.

While this is also a rather sugary issue (excepting those
languages, such as PL/I and Basic, which overload '=' to
mean EITHER assignment OR comparison depending on context;
THAT one is pretty bitter...!-), it interacts with letting
assignment be an expression, _and_ the lack of a specific
'boolean' type exclusively accepted as argument to if/while,
to produce a serious problem.  Each of the three choices
is arguably defensible by itself, but all three together
mix badly.  Python has chosen to NOT allow assignments as
expressions; I'm not sure that is the "best" solution,
but, it _is_ a solution.  In a C context, though, I'd
lean to a different solution -- syntax restriction on what
is accepted in a 'condition' (comparisons, &&, ||, ...,
yes, but not assignments, &, |, ...).  Note that this
doesn't mean I would disallow assignment _as a part_ of
what goes on in a 'condition' -- any current C use of
    while(<whatever>)
could be included, but, at worst, with the syntax:
    while(0!=(<whatever>))
or, equivalently:
    while(!!(<whatever>))
[without necessarily having parentheses around the
<whatever>, if operator priorities allow that].

This, I believe, would be the smallest feasible change to
C's syntax that would substantially reduce the risk of
error.  If one added parenthesized-expressions to the
list of what's to be accepted as 'condition' (not my
top preference), I think most C code that currently
compiles without warnings on gcc -Wall -pedantic would
keep compiling.  Of course, it's all quite acedemic,
but, since you asked...


> Oh, and the C preprocessor
> is a beautiful thing whose absence, in retrospect, makes Pascal seem
> absolutely incomplete.

It's indispensable, yes, but at the same time it's badly
integrated with the language (basically, not at all:-),
for historical reasons (which Ritchie mentions in his paper).


> I guess if I were to pick on C's syntax (without emasculating it), about
> the only thing I could suggest would be "and" and "or" in place of "&"
> and "|". (Oops! I meant "&&" and "||"!)  OK, and I wish TRUE and FALSE
> were permenently defined.

And you would keep "if(a&b == 1)" as meaning "if b is 1 and a is
odd" (like "if(a & (b==1))") rather than "if the only bit set in
both a and b is the lowest one" (like "if((a&b)==1)")...?  Dennis
Ritchie disagrees -- it's one of the various things he now sees
as flaws and quirks in C's syntax, justified by historical
accidents and mistakes (and, of course, the need to keep
backwards compatibility -- Thomas Jefferson DID wish for a
revolution every 20 years or so... he probably had in mind
the need to break backwards compatibility!-).

Anyway -- do have a look at
http://cm.bell-labs.com/cm/cs/who/dmr/chist.html
for some more ideas of things that (were it not for backwards
compatibility needs) the language author's himself might
prefer to see changed.


Alex