C Syntax

[Arthur J. O'Dwyer]

Not that I'm disagreeing, but *is* there any ambiguity avoided
by requiring parens around the condition in a 'do...while' loop?[1]

I don't know about C, but it may have been a holdover from Fortran,
where it does matter:

The Fortran 'DO' is somewhat different from the C 'do', if I
understand correctly. And neither of them is spelled 'if', as
in your examples below, which makes me suspect you didn't really
grasp the point.

! fortran
if (condition = something) then

because
if condition = something

can be also

ifcondition = something

an assignment.

s/can be also/actually means/, of course.

In C I don't see the issue, I admit.

Obviously, that

if foo (bar);

could be treated as either a conditional on foo with (bar); in the body,
or as a conditional on foo(bar) with a null statement in the body.
Requiring an extra set of parentheses around the condition disambiguates
the syntax.

-Arthur


[1] - leaving in the disclaimer for the benefit of jumpers-in...

 

[Arthur J. O'Dwyer]

None of the programming languages assigning semantics to indentation
has ever become mainstream. There must be a reason...

Not true. You're living in the present. In the past, when punch card
input was the norm, indentation had a meaning. In particular, FORTRAN
IV required input to begin in column 7 [...], with a '*' in
column [six] as continuation...

Cobol also (originally) used column-positional syntax, Area A,
Area B, and so on.

Columns 1 through 6 (or 7) was for sequence numbers, followed by
Area A for paragraph names, and Area B for code, but its been a long
time.

At any rate, Dan is incorrect.

No, as far as I can tell Dan is correct in this case (depending
on your definition of "mainstream"). Neither Fortran nor COBOL were
*free-form* languages, but they certainly weren't indentation-sensitive.
See the RPG language for another slightly more modern (but much less
"mainstream") example, IIRC.

Fortran was not indentation-sensitive; in fact, one of the most
widespread anecdotes about Fortran is the "DO20I = 1.10" incident,
which hinges on the fact that Fortran didn't recognize anything
special about whitespace *at* *all*! You could write[1]

C WITH INDENTATION
DO 50 I=1, 99
BOTTLS = 100-I
PRINT 10, BOTTLS
10 FORMAT(1X, I2, 31H BOTTLE(S) OF BEER ON THE WALL.)
50 CONTINUE
STOP
END

or equally

C WITHOUT ANY INDENTATION
DO 50 I=1, 99
BOTTLS = 100-I
PRINT 10, BOTTLS
10 FORMAT(1X, I2, 31H BOTTLE(S) OF BEER ON THE WALL.)
50 CONTINUE
STOP
END

The fact that punch cards in the Good Old Days Before I Was
Born(TM) had designated areas in which it was okay to punch holes
representing code, or line numbers, or comments, has nothing to
do with the concept of "indentation."
See thread
http://groups.google.com/[email protected]
in comp.lang.misc for some discussion tangentially related to
this topic. In fact, I'd suggest this whole discussion move
there, if you want to keep arguing about what's "indentation"
and what's not. Followups set.

-Arthur

[1] - Shamelessly nicked from the 99 Bottles of Beer project
and shortened with a blunt instrument. No warranties on
correctness.

 

[James Kanze]

|> >|> Yet another bogus generalisation coming from Joona. Quoting
|> >|> from a post from a French mailing list:

|> >|> ton enfant ? quel age?

|> >Doubtlessly a typo. Or simply incorrect use.

|> The second is a typo. I work for a french bank, and the vast
|> majority of french expats use spaces before and after emphatic
|> punctuation. Only the anglicised french omit the space.

|> Remind me what this has to do with C....

The French also put spaces before the semicolons in C programs.

 

[Old Wolf]

Besides, how many former Visual Basic programmers were really long-time
"regular" BASIC programmers? Not that large a fraction.

Why do you say that? I thought the whole raison d'etre of VB
was so that people who grew up with BASIC would still be in the
familiar. Why else would anybody use such a horrible language?

 

[Guillaume]

The second is a typo. I work for a french bank, and the vast majority of

french expats use spaces before and after emphatic punctuation. Only the
anglicised french omit the space.

Well, in fact, both are wrong and right at the same time.

Typographically speaking, the kind of spacing that should be used just
before a punctuation mark such as a question mark or an exclamation mark
is NOT the same as the spacing used between two words, for instance.
It should be a "quart de cadratin", which is much less wide.
Unfortunately, plain ASCII text doesn't have much notion of typographic
spacing. It only knows of a basic space, which is as wide as can be.

Thus, I consider putting extra spaces before punctuation marks
a typo when using plain ASCII text, and more esthetically pleasing
to the eye to omit them. French or not.

I especially hate those who put a space before a period. Like this:
"This is fucked up ."

It's just confusing, ugly, and makes no typographic sense.

 

[Stephen Sprunk]

Obviously, that

if foo (bar);

could be treated as either a conditional on foo with (bar); in the body,
or as a conditional on foo(bar) with a null statement in the body.
Requiring an extra set of parentheses around the condition disambiguates
the syntax.

Consider the meanings of

if (foo)(bar);

and

if (foo) (bar);

That one little space changes things drastically.

S

 

[August Derleth]

Why do you say that? I thought the whole raison d'etre of VB
was so that people who grew up with BASIC would still be in the
familiar. Why else would anybody use such a horrible language?

Because Microsoft sells it, and anything they sell for that much money
must be worth buying?

:: Wait for laughter ::

Some schools teach VB. I guess they think it will be an easy language to
learn. Of course, since Python doesn't have a shiny IDE, it isn't a real
language. Besides, that nice Mr. Gates says open source is The DEVIL!

 

[Richard Bos]

No, but the programmers who designed it didn't care about "n00bs";
their target audience was people who worked at Bell Labs. They were
all very very smart.
Erm...


Profound anti-intellectualism among practitioners, and cargo-cult
imitation.

....don't you think these two statements are contradictory?

Richard

 

[Richard Bos]

[ Please do not snip attribution lines of people whose text you leave in
your replies. I have no idea who wrote the following: ]

Python programs are easier to read and understand, that's what I understand
as "clear".

Pardon me: _you_ consider Python programs to be easier to read and
understand. Other people, amongst whom the twice-quoted contributer
above and myself, disagree.

Richard

 

[Arthur J. O'Dwyer]

Consider the meanings of
if (foo)(bar);
and
if (foo) (bar);

That one little space changes things drastically.

For the benefit of jumpers-in: That one little space changes things
drastically only in some hypothetical language that is NOT C. C not
only treats most whitespace the same as a single space; it also ignores
most of it. Spaces around parentheses, for example, don't mean squat.
And I wouldn't want to risk programming in a language that *did* assign
critical meaning to single spaces, especially unobtrusive ones like
that.

-Arthur,
signing off

 

[I. Appel]

Well, I had to place more IMO's, but check this:

foo = lambda x, y: [str (i+j) for (i,j) in zip(x,y)]

Well, it's not very clear, but how many lines of code in C
would be required to reproduce it? Types of x and y can be
either lists of lists, lists of strings, lists of numbers
or strings. And it maybe used for all that stuff.

I don't understand, how several dozens lines of code can be
better than ONE line of code in non-esoteric language.

Read "Succinctness is Power" and "Revenge of the Nerds" by Paul
Graham, if you want more.


Ivan.

[ Please do not snip attribution lines of people whose text you leave in
your replies. I have no idea who wrote the following: ]

twice.

Python programs are easier to read and understand, that's what I understand
as "clear".

Pardon me: _you_ consider Python programs to be easier to read and
understand. Other people, amongst whom the twice-quoted contributer
above and myself, disagree.

Richard

 

[Dan Pop]

Column 6 was for the continuation. Your code had to fit in columns
7 through 72. 73 through 80 was for a card sequence number, and
ignored by the compiler, IIRC.

Cobol also (originally) used column-positional syntax, Area A,
Area B, and so on.

Columns 1 through 6 (or 7) was for sequence numbers, followed by
Area A for paragraph names, and Area B for code, but its been a long
time.

At any rate, Dan is incorrect.

Why? None of these examples count as indentation being semantically
significant. You're merely confusing the fixed format of certain
languages and indentation.

FYI: I've used both fixed format Fortran and fixed format assemblers,
but fixed format has nothing to do with *indentation* being semantically
significant.

Dan

 

[Dave Vandervies]

C has plenty of ambiguity:

I see no ambiguity here. Things that may not match what you want, yes.
If you hate C so much, why do you still use it?

- Braces are optional if there is only one statement for if() or for() or
while(). (But not for do ... while(), switch, or structure/union
declarations.)

There is always precisely one statement controlled by if, for, while, or
do..while (and even switch, though it's rather useless there). That one
statement may be a simple expression statement or a compound statement;
compound statements (by definition) begin with a '{' and end with a '}'.

struct and union declarations don't involve any statements, so your
claim is meaningless when applied to that.

- If a statement has multiple side effects, the order in which those side
effects take place can be unknown.

If a statement has multiple side effects whose order is relevant,
it shouldn't've been written as a single statement in the first place.
If the only purpose of defining something is so that you can look at the
language definition to find out what bad code is really doing, it's not
worth defining.

- The right shift operator may or may not sign extend signed integers. Its
implementation defined.

Is there any reason why it should be defined in some particular way?
If you want sign extension of signed integers, use the division operator;
any self-respecting compiler will use a shift instruction for that where
it's appropriate. If you want to move the bits around without worrying
about sign bits, use unsigned integers and avoid the sign bit entirely.

- The size of an integer is platforms specific.

So? Do you care if the machine gives you 16 more bits than you need?

- The number of bits in a bytes is platform specific.

So? Do you care if the system gives you 2 more bits than you need?

- Try this one on for size:

char a = -1, b = -2;
unsigned short x = (1 > 0) ? a : b;

printf ("x = %d\n", x);

What do you think is printed out? Explain it.

A number that, if you think about it hard enough, will give you some clue
about whether char is signed and possibly about how signed integers are
represented internally.
You're lying to printf; what did you expect, a compiler error saying
"That's not what you meant"?


dave

 

[Slartibartfast]

None of the programming languages assigning semantics to indentation
has ever become mainstream. There must be a reason...

TTCN. It's mainstream if you work in telecoms, but, as your comment
implies, it's unpleasant in the extreme.

 

[Guillaume]

Pascal and C are of the same age almost. Pascal maybe 2-3 years older than

C, not more

Well, technically, you're right. Pascal was officially unveiled at about
the same time as C appeared, but the whole history behind Pascal (and
Ada) is a lot older.

To me, Pascal remains the language of choice to teach a structured,
procedural language. C was originally made to be used by experienced
programmers, and (even if that will raise some eyebrows here and there)
I think this still applies nowadays.

Python programs are easier to read and understand, that's what I understand
as "clear". And I had never such problems as leaving behind tabs or spaces,
it's generally no problem with good text editor.

That's a matter of taste, I guess. Many of us seem to disagree, though.

As for the indentation-oriented syntax, I strongly advise against it.
To me, it's very unnatural. In the huge majority of languages (natural
or programming ones), spaces are meant to be separators and esthetic
elements. Even if indenting has become natural for most programmers
when writing different code blocks in most languages (C, Pascal, Ada...)
I still think it's a visual improvement for readability - and shouldn't
be anything else. I really can't figure out the whole rationale behind
the Python syntax. And even if you claim that "such problems as leaving
behind tabs or spaces, it's generally no problem", it's not quite what
I have in mind in terms of "syntactic robustness".

 

[Ben Pfaff]

...don't you think these two statements are contradictory?

No. The practitioners and imitators are (mostly?) not the people
who worked at Bell Labs and designed C.

 

[Alan Balmer]

Not true. You're living in the present. In the past, when punch card
input was the norm, indentation had a meaning. In particular, FORTRAN
IV required input to begin in column 7 (or was it 8?), with a '*' in
column 6(7) as continuation...

DISCLAIMER: It's been nigh onto 25 years since I've done FORTRAN IV.
My info on the specific columns may be incorrect.

Fortran IV had a fixed format for cards, but indentation was not
meaningful. The code area started in column 7, but you could use
whitespace any way you liked within that constraint. It did not assign
any semantics to indentation, as Python does.

BTW, your attributions are messed up - I didn't write anything you
quoted.

 

[James Kanze]

|> > The second is a typo. I work for a french bank, and the vast
|> > majority of french expats use spaces before and after emphatic
|> > punctuation. Only the anglicised french omit the space.

|> Well, in fact, both are wrong and right at the same time.

|> Typographically speaking, the kind of spacing that should be used
|> just before a punctuation mark such as a question mark or an
|> exclamation mark is NOT the same as the spacing used between two
|> words, for instance. It should be a "quart de cadratin", which is
|> much less wide.

Not much less. A "cadratin" is a quad in English -- originally, a
square piece of lead, whose width is the same as its height. The space
before "high" punctuation is an "espace fine", nominally a fourth of a
quad. The nominal width of a space between words is a third of a quad.
For twelve point type, we're talking about 3pt vs. 4pt. And the 4pt
interword space can be stretched OR SHRUNK somewhat to make the line
fit; on a tightly spaced line, it takes a good eye to see the difference
between an espace mot and an espace fine.

|> Unfortunately, plain ASCII text doesn't have much notion of
|> typographic spacing. It only knows of a basic space, which is as
|> wide as can be.

Agreed. It's even wider than a normal word space.

|> Thus, I consider putting extra spaces before punctuation marks a
|> typo when using plain ASCII text, and more esthetically pleasing to
|> the eye to omit them. French or not.

As someone used to reading French, I find it jarring if there isn't some
space. And the space I expect isn't that far from the normal word space
that it bothers me.

Of course, when I"m typing or reading English or German, I use different
rules.

|> I especially hate those who put a space before a period. Like this:
|> "This is fucked up ."

Quite. At least in the typographical conventions I'm familiar with:
French, German and English. Given the variety, I wouldn't really
surprise me if this were the norm for some language, however.

 

[Keith Thompson]

Well, technically, you're right. Pascal was officially unveiled at about
the same time as C appeared, but the whole history behind Pascal (and
Ada) is a lot older.

C grew out of the same history as Pascal; they're both descendents of
Algol, though C is less of a direct descendent. C's declaration
syntax, at least in its simple forms, is more Algol-like than Pascal's
is:

Algol: integer i;
C: int i;
Pascal: i: integer;

As for the indentation-oriented syntax, I strongly advise against it.
To me, it's very unnatural. In the huge majority of languages (natural
or programming ones), spaces are meant to be separators and esthetic
elements. Even if indenting has become natural for most programmers
when writing different code blocks in most languages (C, Pascal, Ada...)
I still think it's a visual improvement for readability - and shouldn't
be anything else. I really can't figure out the whole rationale behind
the Python syntax. And even if you claim that "such problems as leaving
behind tabs or spaces, it's generally no problem", it's not quite what
I have in mind in terms of "syntactic robustness".

(As long as we have an '[OT]' tag on this thread ...)

I haven't played with Python enough to form a strong opinion about its
indentation-oriented syntax, but I think I like it. When I program in
a language that expressions nesting with delimiters (begin/end, {/},
case/esac), I maintain strictly consistent indentation anyway. I go
to the effort of indenting my code properly, and the compiler doesn't
even warn me if I get it wrong. Python lets me omit the delimiters;
the indentation is exactly what it would have been if Python required
delimiters as well.

C's use of delimiters to denote nesting allows some flexibility that
Python doesn't, but I see no virtue in that flexibility. C allows
incorrect, or even misleading, indentation:

if (cond1)
if (cond2)
some_statement;
else
some_other_statement;

 

[I. Appel]

Well, technically, you're right. Pascal was officially unveiled at about
the same time as C appeared, but the whole history behind Pascal (and
Ada) is a lot older.

The concepts behind them are almost the same. Maybe C is a bit more
influenced
by low-level programming and functional programming, but it's as structured
as Pascal.

To me, Pascal remains the language of choice to teach a structured,
procedural language. C was originally made to be used by experienced
programmers, and (even if that will raise some eyebrows here and there)
I think this still applies nowadays.

I can't disagree with you. When I studied programming at my university,
it was really hard for inexperienced people to code in C. I suppose, it
would be pretty simpler for them to learn Pascal first.

Some Python and Java zealots suppose their stuff to be the best learning
language instead of Pascal, but I'm not agree.

That's a matter of taste, I guess. Many of us seem to disagree, though.

I've seen code in C and Java written by several Python-haters. Most of them
don't use indents at all, so their code is pretty hard to read. See below.

As for the indentation-oriented syntax, I strongly advise against it.
To me, it's very unnatural. In the huge majority of languages (natural
or programming ones), spaces are meant to be separators and esthetic
elements. Even if indenting has become natural for most programmers
when writing different code blocks in most languages (C, Pascal, Ada...)
I still think it's a visual improvement for readability - and shouldn't
be anything else. I really can't figure out the whole rationale behind
the Python syntax. And even if you claim that "such problems as leaving
behind tabs or spaces, it's generally no problem", it's not quite what
I have in mind in terms of "syntactic robustness".

Well, main idea behind Python's syntax is "we use indentation anyway (most
of
us at least), so what's the reason to make syntax redundant and to use
_both_
indents and delimiters?"

Are you agree?