C Syntax

[Dan Pop]

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

 

[I. Appel]

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.

 

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

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.

 

[Dan Pop]

(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

 

[Mike]

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

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?

 

[Keith Thompson]

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

 

[I. Appel]

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.