C Syntax

[C# Learner]

Why is C syntax so uneasy on the eye?

In its day, was it _really_ designed by snobby programmers to scare away
potential "n00bs"? If so, and after 50+ years of programming research,
why are programming languages still being designed with C's syntax?

These questions drive me insane. Every waking minute...

[Dan Pop]

In <40bd955e.341957500@news-server> oz****@bigpond.com (ozbear) writes:

On 1 Jun 2004 15:29:53 GMT, Da*****@cern.ch (Dan Pop) wrote:

In <40bafec8.172335531@news-server> oz****@bigpond.com (ozbear) writes:

On 29 May 2004 19:35:09 -0700, re********@yahoo.com (red floyd) wrote:

Da*****@cern.ch (Dan Pop) wrote in message news:<c9**********@sunnews.cern.ch>...
> In <bu********************************@4ax.com> Alan Balmer <al******@att.net> writes:

> 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 (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.

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.

Nope. "Fixed format" is just a ruse to cover up what is actually
fixed indentation. If those rules were violated you didn't even
get to what was semantically equivalent because you never got past
compilation.

If you put your Fortran continuation character in the wrong column
you could easily end up with errors.

The point is that those columns had meaning to the compiler hence one
had to indent, hence indentation had meaning.

You're confusing fixed format and indentation. No amount of indentation
past column 7 has any semantic meaning in any Fortran version I'm familiar
with. Fixed format Fortran *completely* ignores any space character that
is not part of a "string literal". Because of this, it is sheer idiocy to
claim that indentation plays any *semantic* role in fixed format Fortran.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[I. Appel]

"Alan Balmer" <al******@att.net> wrote in message
news:f3********************************@4ax.com...

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.

As you said, it's not very clear ;-) Actually, you'll have to define
"better" before you're qualified to offer an opinion.

What is the reason to have syntax that is clearer-per-line, if it
requires to write several times more lines of code?

Ivan.

[I. Appel]

"Alan Balmer" <al******@att.net> wrote in message
news:b9********************************@4ax.com...

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 (mostof
us at least), so what's the reason to make syntax redundant and to use
_both_
indents and delimiters?"

Are you agree?

Nope.

Well, it's a matter of taste and habits (some of had to tell that :-))), so
let's stop discussion here. I like syntaxes of both C and Python, while I
consider,
that both have their disadvantages.

Ivan.

[Dan Pop]

In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:

(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.

If the ASCII HT character (and its likes in other character sets,
represented as \t in C) hadn't been invented or had very solidly defined
semantics, I would have agreed with your analysis. Unfortunately, their
invention as loosely defined control characters opened Pandora's box...

The immediate reaction to this remark: "if you never use them, their
existence doesn't hurt you" is, unfortunately, too naive:

1. Even if you don't, someone else may. With different semantics than
your defaults. People dealing with other people's code are probably
well aware of the issue. But in C, the block delimiters provide all
the information needed for fixing the indentation broken by the HTs...

2. Even if you don't, some text processing utilities may do it behind your
back. A typical example is vi, which "optimises" the storage of the
saved text by replacing multiple spaces by HTs according to the ts
variable setting. Since I have found no portable way of disabling this
feature, I'm setting ts to 100 in my .exrc.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Mike]

> > >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.

As you said, it's not very clear ;-) Actually, you'll have to define
"better" before you're qualified to offer an opinion.

What is the reason to have syntax that is clearer-per-line, if it
requires to write several times more lines of code?

The functional versional would be compact and neat, but almost certainly
slower to exectue; the imperative version would be bigger, uglier, but most
probably faster. No one can claim that one is better than another, as it
completely depends on what you are trying to achieve.

Mike

[cody]

> 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.

Now one question arises: What exactly does this piece of code do?

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

[Keith Thompson]

Da*****@cern.ch (Dan Pop) writes:
[...

2. Even if you don't, some text processing utilities may do it behind your
back. A typical example is vi, which "optimises" the storage of the
saved text by replacing multiple spaces by HTs according to the ts
variable setting. Since I have found no portable way of disabling this
feature, I'm setting ts to 100 in my .exrc.

I'm not quite willing to do that, but I do have the following in my
$HOME/.exrc:

map ]^V^I :%!expand^M

where the carets denote the obvious cotro characters.

As I enter code, vi (I use nvi) insists on changing each 8 columns of
indentation to a tab, but before saving the file I can hit a
right-bracket followed by a tab and expand everything to spaces
(unless I'm writing a Makefile, of course).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[I. Appel]

"Mike" <no***@hotmail.com> wrote in message
news:#y**************@tk2msftngp13.phx.gbl...

>foo = lambda x, y: [str (i+j) for (i,j) in zip(x,y)]
>
>I don't understand, how several dozens lines of code can be
>better than ONE line of code in non-esoteric language.

As you said, it's not very clear ;-) Actually, you'll have to define
"better" before you're qualified to offer an opinion.
What is the reason to have syntax that is clearer-per-line, if it
requires to write several times more lines of code?

The functional versional would be compact and neat, but almost certainly
slower to exectue; the imperative version would be bigger, uglier, but

most probably faster. No one can claim that one is better than another, as it
completely depends on what you are trying to achieve.

I agree with you, but the discussion is about _clear_ syntaxes.

Ivan.