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

[C# Learner]

Grumble wrote:

C# Learner wrote:

Simply:

1) Remove the need to specify parentheses for test conditions --
substitute a test condition terminator, such as Python's ':'.

#define if if (
#define then )

int main(int argc, char **argv)
{
if argc-1 == 0 then return 666;
return 0;
}

Point taken. :-)

Still, though, if others don't do this, then, when reading others' code,
the problem (as I see it) is still there.

[C# Learner]

I. Appel wrote:

[...]

I'd say Delphi has the clearest syntax.

Delphi is boring. IMO syntax of C is much more funny.

<my opinion>
Delphi code is, in general, much more readable than C code. Therefore,
Delphi coders have an easier life than C coders.
</my opinion>

[...]

[Alan Balmer]

On Thu, 27 May 2004 21:08:47 +0100, C# Learner <cs****@learner.here>
wrote:

My point is that a different construct could be substituted in each case.

Making the syntax more complex, for no particular benefit that I can
see.

Parentheses, brackets and braces represent the general concept of
grouping. Even when seen in an unfamiliar context, one can get the
idea. I see no need to invent a different grouping symbology for each
use.

Everyone understands the symmetry between '(' and ')'. The symmetry
between 'if' and ':' is not nearly as intuitive. And now you propose
that each case that requires a grouping operator have a different
construct?

Of course, you say "could be substituted", which is obviously true. It
would certainly add a new dimension to the obfuscated C contests.

--
Al Balmer
Balmer Consulting
re************************@att.net

[Mike Wahler]

"C# Learner" <cs****@learner.here> wrote in message
news:Or**************@TK2MSFTNGP12.phx.gbl...

Grumble wrote:

C# Learner wrote:

Simply:

1) Remove the need to specify parentheses for test conditions --
substitute a test condition terminator, such as Python's ':'.

#define if if (
#define then )

int main(int argc, char **argv)
{
if argc-1 == 0 then return 666;
return 0;
}

Point taken. :-)

Still, though, if others don't do this, then, when reading others' code,
the problem (as I see it) is still there.

The 'problem' of not understanding a language's syntax,
is solved by learning it.

The 'problem' of disliking a language's syntax,
is solved by using a different language (whose syntax you
do like).

-Mike

[Mark McIntyre]

On Thu, 27 May 2004 21:11:28 +0100, in comp.lang.c , C# Learner
<cs****@learner.here> wrote:

Mark McIntyre wrote:

Okay, I'll bite. Why on earth do you consider this in any way an
improvement? What difference does it make to anything?
I believe that it'd improve code readability.

I disagree. The delimiter helps mark the ends of the various parts of the
statement. With only whitespace to work with, compound statements become
almost impossible to correctly read.
Have you noticed how, in
langauges which use such syntax, .....they use spaces because of the fact that parentheses are used both
in test conditions and function calls. As far as I see, when doing so,
they're just attempting to work around a syntactical design flaw of the
language.

Gonads. This is nothing more than a style thing. French people put two
spaces after a full stop. English people don't. Same idea.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[E. Robert Tisdale]

C# Learner wrote:

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

This is an obvious troll. Please Ignore it.

[Keith Thompson]

Grumble <a@b.c> writes:

C# Learner wrote:

Simply:
1) Remove the need to specify parentheses for test conditions --
substitute a test condition terminator, such as Python's ':'.

#define if if (
#define then )

int main(int argc, char **argv)
{
if argc-1 == 0 then return 666;
return 0;
}

Yes, that's very clever. Please don't do it in any code that I might
ever have to maintain, or read -- or that anyone else might ever have
to maintain or read.

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

[Keith Thompson]

qe*@pobox.com (Paul Hsieh) writes:
[...]

C has plenty of ambiguity:

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

That's not an ambiguity, it just means there's more than one way to
write a given program. The fact that braces are optional in many
contexts does not imply that there is any C program that can be
interpreted in any of two or more ways; the interpretation is
unambiguous in each case.

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

[Keith Thompson]

C# Learner <cs****@learner.here> writes:

Kieran Simkin wrote:

[...]

Obviously this entire post is off-topic. Python is not C, C will never be
Python and you've cross-posted to C# which is not C either.

Hmm... I have to disagree. I feel that this discussion is about C's
basic syntax and its ubiquity in popular modern-day languages.

If such a discussion is off-topic for comp.lang.c, then I honestly
don't know quite where it would be /on/-topic. In fact, I even
considered renaming the subject of this post to 'Re: C Syntax', but
didn't want to enrage people by doing so.

Discussion of how other languages have influenced C would be topical
in comp.lang.c. Discussion of how C has influenced a hypothetical
language Foo would be topical (I presume) in comp.lang.foo. But if
you want to discuss how C has influenced other languages in general,
that's probably a good topic for comp.lang.misc.

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

[Old Wolf]

Da*****@cern.ch (Dan Pop) wrote:

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

The language of makefiles?
(Before you say "it isn't a language", it seems to be as much
a language as Prolog is)

[Joona I Palaste]

Mark McIntyre <ma**********@spamcop.net> scribbled the following:

On Thu, 27 May 2004 21:11:28 +0100, in comp.lang.c , C# Learner
<cs****@learner.here> wrote:

Mark McIntyre wrote:

Okay, I'll bite. Why on earth do you consider this in any way an
improvement? What difference does it make to anything?
I believe that it'd improve code readability. I disagree. The delimiter helps mark the ends of the various parts of the
statement. With only whitespace to work with, compound statements become
almost impossible to correctly read. Have you noticed how, in
langauges which use such syntax,

....

they use spaces because of the fact that parentheses are used both
in test conditions and function calls. As far as I see, when doing so,
they're just attempting to work around a syntactical design flaw of the
language.

Gonads. This is nothing more than a style thing. French people put two
spaces after a full stop. English people don't. Same idea.

I've seen plenty of English-speakers (at least USAns) write two spaces
atfer a full stop. Now the French, they put a space before an
exclamation or question mark. Like this: "Regardez moi ! Je suis
français !". What's with that, then?

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Hasta la Vista, Abie!"
- Bart Simpson

[Keith Thompson]

C# Learner <cs****@learner.here> writes:

Mark McIntyre wrote:

On Thu, 27 May 2004 00:56:59 +0100, in comp.lang.c , C# Learner
<cs****@learner.here> wrote:

One of the biggest flaws in C syntax, in my opinion, is the
required parentheses for test conditions.

if (FooBar(Parse(Process(GetInput())))
DoSomething();

(he prefers)

if FooBar(Parse(Process(GetInput())):
DoSomething();

Okay, I'll bite. Why on earth do you consider this in any way an
improvement? What difference does it make to anything?

I believe that it'd improve code readability. Have you noticed how,
in langauges which use such syntax, people often write something like:

if ( FooBar(Parse(Process(GetInput())) )

i.e. they use spaces because of the fact that parentheses are used
both in test conditions and function calls. As far as I see, when
doing so, they're just attempting to work around a syntactical design
flaw of the language.

I'm beginning to think your argument boils down to
I like Python.
I don't like C.

If you'd stated it that way, I'm sure everyone here would be in
complete agreement with you. We all agree that you like Python, and
we all agree that you don't like C.

Yes, I'm oversimplifying your argument and having a little fun at your
expense.

I think there's a valid point in here somewhere. Perhaps what you're
really looking for is a language with something like C's relatively
low-level semantics, but with Python's <OPINION>superior</OPINION>
syntax. I'm not aware that any such language exists. If it did, I
might prefer it to C myself. But of course it would be off-topic
here.

Another valid question is why C's <OPINION>ugly</OPINION> syntax has
had such an effect on later languages. As I mentioned elsethread,
that's probably a good topic for comp.lang.misc; you might check the
Google archives of that newsgroup.

Significant changes to C's syntax are not possible due to the need to
accomodate existing code. And such changes would be considered
undesirable by most C programmers, who either have gotten used to C's
quirks or actually like them. There are certainly some things I would
do differently if I were designing C from scratch today, but that's
probably very different from the set of changes someone else would
want to make.

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

[Keith Thompson]

C# Learner <cs****@learner.here> writes:
[...]

a) Valid C syntax:

if (foo &&
bar) {
foobar();
}

b) Similar code to the above but using my suggested syntax changes:

if foo &&
bar:
foobar();

Why wouldn't (b) be feasible here?

I don't believe that Python has the ?: operator. C does. I don't
know whether it would cause any genuine ambiguities for the proposed
"if ... :" syntax, but it could certainly cause confusion.

If I were going to propose such a change (I'm not), I might suggest
dropping the parentheses and making the braces around the controlled
statement mandatory. For example:

if foo &&
bar
{
foobar();
}

I think similar changes could consistently be made for other compound
statements.

Of course, it's never going to happen.

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

[C# Learner]

Keith Thompson wrote:

[...] There are certainly some things I would
do differently if I were designing C from scratch today, [...]

This is basically what I've had set in my mind while participating in
this thread.

I think I've finally found someone who's tuned into my wavelength,
perhaps; in any case, someone who truly understands my motive.

:-)

[Justin Rogers]

"C# Learner" <cs****@learner.here> wrote in message
news:%2***************@TK2MSFTNGP09.phx.gbl...

Keith Thompson wrote:

[...] There are certainly some things I would
do differently if I were designing C from scratch today, [...]

This is basically what I've had set in my mind while participating in
this thread.

I think I've finally found someone who's tuned into my wavelength,
perhaps; in any case, someone who truly understands my motive.

:-)

While Keith points out there are some things he would do differently, C#
is in essence the attempt at an entirely new language, and yet they kept all
of the older syntax. Anders was a Pascal guy, and yet he chose the
constructs he did in his custom tailored language why? Well, because he
thought they provided the most power for the language without denying users
access to some commonly used programming tools.

The first tool is debugging and error assessment. The strict language
guidelines
of C# make it very easy to discover the root of a lexical or parsing error. At
the same time they make it easy to point out and find common programming
mistakes.

Verbosity or the lack thereof as a tool:
Take language constructs like begin...end to designate blocks... They
are verbose, why not just type { and }, after all this is much shorter. Why do
I need to separate my code by all that whitespace:

if something:
foobar

When I could easily write it on one line without all of that crappy whitespace

if ( something ) { foobar; }

What about intellisense and other features users have grown to love? Are they
easier,
faster, more efficient when written against a C type language? Does the explict
bounding of statement/expression/block scopes help the underlying intellisense
processor
to more accurately understand what the user is doing? Does it remove levels of
ambiguity
that would otherwise exist? When does whitespace become important, when is it
not,
does tabs to spaces or spaces to tabs affect the compilation of your
application? What
happens to whitespace nested blocks when I use two spaces per indent, but
convert to
tabs that are 4 to 8 spaces per indent? Does my code resize properly or do all
of my 2/4/6
spaces get turned into a single tab. Does a tab count as a single indention
character or
multiple? For instance, does a single space or a single tab have the same
nesting depth?

There are so many more aspects to programming today than loading up your
favorite
text editor and hacking away in the most efficient form that you can manage.
Code generators,
intellisense, auto-complete, are all tools taking up precious processor time
trying to figure
out what you want to do, and I think the trade-off between some extra semantics
versus
confusing the hell out of the computer that is making my life a bit easier, is
something I'm quite
happy with.
--
Justin Rogers
DigiTec Web Consultants, LLC.
Blog: http://weblogs.asp.net/justin_rogers

[Michael Voss]

From a thread started in comp.lang.c

Irrwahn Grausewitz wrote:

"Michael Voss" <mi**********@lvrREMOVE.deCAPS> wrote:

Irrwahn Grausewitz wrote:
[...snip...]

Smalltalk is a functional language.
How do you define "functional language" ?

I don't - others already did. If you're interested in this subject
I suggest to Go Ogle for the comp.lang.functional FAQ - it contains
a nice explanation of functional vs. procedural programming paradigms.

<COMPLETELY OFF TOPIC EXCEPT FOR C.L.F>
My Google search revealed nothing except that other people are searching the
c.l.f FAQ, too. Any hint where I could find them ?
</COMPLETELY OFF TOPIC EXCEPT FOR C.L.F>

Ob the portion you snipped: While both C++ and Smalltalk are OO
languages, the former is a mere procedural, the latter a mere
functional language.

If a functional language is defined as:

--"The idea of functional languages is that functions are
--completely determined by their parameters. If you put
--the same parameters to a function, then you must get the
--same return values. So a function which does not take any
--parameters should always return the same result."
(Christian Szegedy (sz*****@nospam.or.uni-bonn.de) in comp.lang.functional
at 2004-03-19 07:19:21 PST),

In my eyes and regarding the above definition, Smalltalk is not a functional
language.

Since I crossposted this to comp.lang.smalltalk and comp.lang.functional:
What do you think ? Is Smalltalk an object-oriented "mere functional"
language ?
Since this is completely off-topic for c.l.c and m.p.d.l.c, and my
newsreader does not support a proper followup-to (blush): Please followup to
comp.lang.smalltalk and comp.lang.functional. Please remove the C /
C#-groups.

Thanks,
Michael

[Richard Bos]

C# Learner <cs****@learner.here> wrote:

a) Valid C syntax:

if (foo &&
bar) {
foobar();
}

b) Similar code to the above but using my suggested syntax changes:

if foo &&
bar:
foobar();

Why wouldn't (b) be feasible here?
Because it is _not C_. If you want to design your own language, fair
enough. Hundreds if not thousands of people have done so before. Hey,
why don't you try to get M$ to change their Stolen-Java-with-an-
inappropriate-name syntax to include your pet love? At least then you
wouldn't have to convince so many people to change code that's been
working correctly for years or even decades.

As you study and understand the language, you'll find that it's all
nicely consistent, and that there are good reasons for most of the
features which seem odd to you.

The only way in which they seem odd to me is that they make code much
less readable than it could be, in my opinion.

_Your_ opinion does not count for much (any more than mine) against an
existing language with probably tens (if we count all hobbyists,
hundreds) of thousands of users all over the world.
Okay, if you don't agree with the 'if'..':' idea, then how about
changing the parentheses required for test conditions for a different
pair of characters?
No.
An ideal pair would be a pair that isn't used
elsewhere in the language, for readability's sake.

Name one.

Also, think about the fact that language inventors and implementers
are, by and large, a pretty bright bunch. In general, they probably
have more and wider experience in the field than you do, and some of
them might even be as smart ;-)

So those who invented C's syntax are necessarily brighter than those who
invented, say, Python's syntax?

Not necessarily, though I must say I find Python's forced indentation a
veritable pain in the butt, and it is one of the main reasons why I
don't use the language.

Those features which have passed
through to modern languages have done so for a reason.

I honestly wonder what that reason is.

People found them useful. Better programmers than you found them useful.

Richard

[Richard Bos]

C# Learner <cs****@learner.here> wrote:

Keith Thompson wrote:

[...] There are certainly some things I would
do differently if I were designing C from scratch today, [...]

This is basically what I've had set in my mind while participating in
this thread.

Then I suggest you bloody well _do_ so, instead of bothering the users
of two existing languages, only related to eachother in name, about it.
If your language really does turn out to be superior to the existing
candidates, I'm sure you'll have no problems getting people to program
in it.

Richard

[Richard Bos]

Joona I Palaste <pa*****@cc.helsinki.fi> wrote:

Mark McIntyre <ma**********@spamcop.net> scribbled the following:

Gonads. This is nothing more than a style thing. French people put two
spaces after a full stop. English people don't. Same idea.

I've seen plenty of English-speakers (at least USAns) write two spaces
atfer a full stop.

USAnians != English, and I believe you know Inform? Guess what its -d
option is for?

Richard

[The Real Andy]

On Wed, 26 May 2004 20:42:39 -0400, Lew Pitcher
<lp******@sympatico.ca> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

C# Learner wrote:
| Why is C syntax so uneasy on the eye?

%<

I am a former embedded programmer. I started programming with
assembler. C was a godsend. If you think the C syntax is uneasy on the
eye, then try learning 10 different assembler languages and using them
on a day to day basis. Try then to go back a year to maintain the
flavour of assembler from that period.

[C# Learner]

Justin Rogers wrote:

While Keith points out there are some things he would do differently, C#
is in essence the attempt at an entirely new language, and yet they kept all
of the older syntax. Anders was a Pascal guy, and yet he chose the
constructs he did in his custom tailored language why?
Good question! :-)
Well, because he
thought they provided the most power for the language without denying users
access to some commonly used programming tools.

I also wonder to what extent he was required to keep the language
looking like C++/Java, and therefore attractive to current C++/Java
programmers. This is pure speculation on my part, of course; but I see
signs of it in the language, with an example being the 'switch'
construct. The syntax of 'switch' constructs is very different to that
of other syntactical elements of C#, and it seems to stick out like a
sore thumb. It appears that it was copied straight from C (although
with a difference in that C#'s version doesn't allow implicit fall-through).

<snip>

[Dmitry Zamotkin]

> --"The idea of functional languages is that functions are

--completely determined by their parameters. If you put
--the same parameters to a function, then you must get the
--same return values. So a function which does not take any
--parameters should always return the same result."

he-he.
C is not functional too.
Try rand() function.

--
Dmitry Zamotkin

[Justin Rogers]

I'll actually bite on the below since I have some input. There was a Java
to IL compiler written before C# made it's first test runs, so I can't see
Java being the *look*. Managed C++, while syntactically appearing to
be a hack, was powerful enough to handle the C++ style syntax.

The reason for the way the switch statement in C# is works is the manner
in which the underlying IL construct works. In IL a switch is nothing more
than a simple jump table. They don't provide fall through because that
would require automatic generation of goto statements within the case
statement body. In most cases fall-through in C led to unexpected results
as users failed to close the syntax when that is what they meant to do.

As for the strange look of a switch, it is a balance of verbosity and function.
You might say that each case statement could indeed be it's own block and
should use french braces the way the rest of the language does, but that
doesn't allow for any form of fall-through.

case 10 { block } case 20 { block }

Where do you fall through in the above block? How do you have the
equivalent limited fall through syntax that C# does allow?

case 10:
case 20:
break;

Note, you are also building from the concepts of a label, each case
statement is terminated by a colon, something you don't find anywhere
else in C#, yet it is there. Each case statement semantically becomes a
label of some sort, a jump table label if you will. No different from having
an OUTER: label within a loop so that you can break out of the internal
loop and continue processing the outer loop.

What I'd highly recommend is write a lexer/parser that targets C# and then
change the language the way you'd like to see it changed. See how hard/easy
it is to format the code in your new manner and see how scalable that is for
adding new features. Would, for instance, you changes to the language have
affected the almost transparent addition of generics? What about namespace
aliasing and anonymous delegates? The future of the language is just as
important
as it's past, and C# is quickly becoming a very unique and promising language in
many ways.
--
Justin Rogers
DigiTec Web Consultants, LLC.
Blog: http://weblogs.asp.net/justin_rogers

I also wonder to what extent he was required to keep the language
looking like C++/Java, and therefore attractive to current C++/Java
programmers. This is pure speculation on my part, of course; but I see
signs of it in the language, with an example being the 'switch'
construct. The syntax of 'switch' constructs is very different to that
of other syntactical elements of C#, and it seems to stick out like a
sore thumb. It appears that it was copied straight from C (although
with a difference in that C#'s version doesn't allow implicit fall-through).

<snip>

[Grumble]

Keith Thompson wrote:

Grumble wrote:

#define if if (
#define then )

int main(int argc, char **argv)
{
if argc-1 == 0 then return 666;
return 0;
}

Yes, that's very clever.

CPP - Exercice #1
http://www.infop6.jussieu.fr/cederom...al-in-cpp.html

:-)

[Irrwahn Grausewitz]

"Michael Voss" <mi**********@lvrREMOVE.deCAPS> wrote:

<COMPLETELY OFF TOPIC EXCEPT FOR C.L.F>
My Google search revealed nothing except that other people are searching the
c.l.f FAQ, too. Any hint where I could find them ?
The first hit googling for "functional language faq"
(without the quotes) is:

http://www.cs.nott.ac.uk/~gmh//faq.html

See section 2.1
</COMPLETELY OFF TOPIC EXCEPT FOR C.L.F> Since this is completely off-topic for c.l.c and m.p.d.l.c, and my
newsreader does not support a proper followup-to (blush): Please followup to
comp.lang.smalltalk and comp.lang.functional. Please remove the C /
C#-groups.

Done.

Regards
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc: http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc OT guide : http://benpfaff.org/writings/clc/off-topic.html

[Mabden]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message
news:c9**********@nntp1.jpl.nasa.gov...

C# Learner wrote:

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

This is an obvious troll. Please Ignore it.

This is an obvious troll-responder. Please ignore it. ;-)

[C# Learner]

Justin Rogers wrote:

<snip>

Would, for instance, you changes to the language have
affected the almost transparent addition of generics? What about namespace
aliasing and anonymous delegates?
Well, I'm not really thinking /that/ much into it -- I'm just thinking
about very basic syntax.

In any case, I look forward to generics, which I feel will make for
slightly more readable code, and perhaps more efficient code.

Anonymous delegates look nice too -- I read an article awhile back about
the ability to use them in an elegant fashion to marshall calls from a
worker thread onto the UI thread.
The future of the language is just as
important
as it's past, and C# is quickly becoming a very unique and promising language in
many ways.

Yeah, definitely. These are exciting times for programmers.

[Dan Pop]

In <c9**********@oravannahka.helsinki.fi> Joona I Palaste <pa*****@cc.helsinki.fi> writes:

Mark McIntyre <ma**********@spamcop.net> scribbled the following:

Gonads. This is nothing more than a style thing. French people put two
spaces after a full stop. English people don't. Same idea.
I've seen plenty of English-speakers (at least USAns) write two spaces
atfer a full stop.

It has nothing to do with the language. It's a common (albeit not
universal) typographic convention to leave more space after the
punctuation sign terminating a sentence then after punctuation signs
inside a sentence. Examine a few printed books carefully and you may
notice it (it's not twice as much, so it's not immediately obvious).

The only way to follow this convention in a plain text document is by
using two spaces instead of one. This is what I'm consistently doing,
no matter in which of the three languages I'm familiar with I'm writing.
Now the French, they put a space before an
exclamation or question mark. Like this: "Regardez moi ! Je suis
français !". What's with that, then?

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

ton enfant ? quel age?

:-)

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

[Dan Pop]

In <84**************************@posting.google.com > ol*****@inspire.net.nz (Old Wolf) writes:

Da*****@cern.ch (Dan Pop) wrote:

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

The language of makefiles?

Indentation per se is meaningless there. It's just that the language
syntax requires a TAB character as the first character on a line in
certain contexts.

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

[I. Appel]

> >>I'd say Delphi has the clearest syntax.

Delphi is boring. IMO syntax of C is much more funny.

<my opinion>
Delphi code is, in general, much more readable than C code. Therefore,
Delphi coders have an easier life than C coders.
</my opinion>

Well, yes. But Python or Visual Basic code is IMO even more readable.

[I. Appel]

> Delphi is Pascal with maybe a few bells and whistles.

Therefore, it's based on an older language than C, maybe that's why
it's a bit boring.

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

Well, rephrasing Paul Graham, I should say "Don't wait until C will become as
clear as Python, use Python instead".

If you really think Python has clearer syntax than C, well, think twice.
One terrible fact is this indentation thing in Python to delimit code
blocks. One tab or space is left behind, and the whole thing is screwed.
To me, it's an unacceptable syntax issue.

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.

[Joe Wright]

Dan Pop wrote:

In <84**************************@posting.google.com > ol*****@inspire.net.nz (Old Wolf) writes:

Da*****@cern.ch (Dan Pop) wrote:

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

The language of makefiles?

Indentation per se is meaningless there. It's just that the language
syntax requires a TAB character as the first character on a line in
certain contexts.

Dan

Usually the Rule starts at the left margin and the Command is on the
next line indented with the TAB character. I always found this TAB a
nuisance because my editor puts spaces out when I press Tab key.

Imagine my joy upon reading that GNU make (if not others) also
allows separating Rule from Command with semicolon.

# Use GNU make to build an executable for testing GE.

cc=gcc
obj=ge.o main.o
exe=main.exe
opt=-W -Wall -ansi -pedantic -O2 -c

# Note that semicolon (not TAB) separates Rule from Command on a line.

$(exe) : $(obj) ; $(cc) -s $(obj) -o $(exe)
ge.o : ge.c ; $(cc) $(opt) ge.c
main.o : main.c ge.h ; $(cc) $(opt) main.c

--
Joe Wright mailto:jo********@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Goran Larsson]

In article <4t********************@comcast.com>,
Joe Wright <jo********@comcast.net> wrote:

Imagine my joy upon reading that GNU make (if not others) also
allows separating Rule from Command with semicolon.

This is a standard make feature. In a way it is the fundamental
method to separate the dependency list from the commands. The
lines startong with TABs are just continuation lines for the commands.

--
Göran Larsson http://www.mitt-eget.com/

[James Kanze]

C# Learner <cs****@learner.here> writes:

|> Alan Balmer wrote:

|> > On Thu, 27 May 2004 04:36:24 +0100, C# Learner <cs****@learner.here>
|> > wrote:

|> [...]

|> > Forgive me if I'm wrong, but my impression is that you don't have
|> > a deep enough understanding of the C language, and indeed of
|> > programming languages in general, to appreciate the reasons for
|> > the syntax features you're commenting on.

|> I believe that I appreciate the reasons for these features. What I'm
|> saying is that I think that there are better (in terms of allowing
|> the user of the language to write readable code) alternatives that
|> could have been implemented instead.

|> > Take your original example of eliminating the deli meters around
|> > the conditional in an if statement. Think about what this would
|> > mean for compound conditions. Combine that with the Python-style
|> > blocking and then think about an if statement which tests for
|> > several conditions, requiring more than one line to write.

|> a) Valid C syntax:

|> if (foo &&
|> bar) {
|> foobar();
|> }

|> b) Similar code to the above but using my suggested syntax changes:

|> if foo &&
|> bar:
|> foobar();

|> Why wouldn't (b) be feasible here?

|> Everything from 'if' to ':' is considered the condition.

Even if there is a ?: operator in the conditional expression?

|> After the newline after ':', whitespace is required to form a code
|> block.

Let's see, you want to overload on whitespace?

|> > As you study and understand the language, you'll find that it's
|> > all nicely consistent, and that there are good reasons for most of
|> > the features which seem odd to you.

|> The only way in which they seem odd to me is that they make code
|> much less readable than it could be, in my opinion.

Things like C's declaration syntax make code less readable. But you
didn't mention that. The preprocessor can be really effective in making
code less readable too, but you didn't mention that either. And of
course, all those funny characters really made code less readable back
in the days when I had to work with an ISO 646 terminal -- in the German
variant.

But you seem to be attacking areas where C basically has no serious
problems. I personally prefer something like:

if expr then
stmt_list
else
stmt_list
endif

but the alternative used by C is pretty acceptable too. (And my
preference may have been conditioned by the ISO 646 terminals above.
Things like:

if ( expr ) ä
stmt_list
ü else ä
stmt_list
ü

are not particularly readable.)

|> Okay, if you don't agree with the 'if'..':' idea, then how about
|> changing the parentheses required for test conditions for a
|> different pair of characters? An ideal pair would be a pair that
|> isn't used elsewhere in the language, for readability's sake.

|> > One of the characteristics of C is terseness, and extra parens
|> > aren't required by the language for no reason.

|> My point is that a different construct could be substituted in each
|> case.

|> > Also, think about the fact that language inventors and
|> > implementers are, by and large, a pretty bright bunch. In general,
|> > they probably have more and wider experience in the field than you
|> > do, and some of them might even be as smart ;-)

Let's not get carried away. Language designers don't work in a vacuum,
and C is like it is for a variety of historical reasons.

|> So those who invented C's syntax are necessarily brighter than those
|> who invented, say, Python's syntax?

They were certainly working in a different context. I don't know
Python, so I can't say, but from the little you've shown, my impression
is that it is something that works well for quick hacks, but doesn't
scale well.

|> > Those features which have passed through to modern languages have
|> > done so for a reason.

|> I honestly wonder what that reason is.

They work.

--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France [phone]

[James Kanze]

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

|> In <c9**********@oravannahka.helsinki.fi> Joona I Palaste
|> <pa*****@cc.helsinki.fi> writes:

|> >Mark McIntyre <ma**********@spamcop.net> scribbled the following:

|> >> Gonads. This is nothing more than a style thing. French people
|> >> put two spaces after a full stop. English people don't. Same
|> >> idea.

|> >I've seen plenty of English-speakers (at least USAns) write two
|> >spaces atfer a full stop.

|> It has nothing to do with the language. It's a common (albeit not
|> universal) typographic convention to leave more space after the
|> punctuation sign terminating a sentence then after punctuation signs
|> inside a sentence.

It is a common (albeit not universal) typographical convention in the
anglosaxon world. Look at a book printed in France or Germany.

Correctly typeset French uses three different spaces :

une espace fine insécable : about a fourth of a quad, no line break
allowed.
une espace mots insécable : about a third of a quad, no line break
allowed.
une espace justifiante : nominally about a third of a quad, but can be
stretched or shrunk, allows a line break.

Nothing larger for the end of a sentence.

|> Examine a few printed books carefully and you may notice it (it's
|> not twice as much, so it's not immediately obvious).

|> The only way to follow this convention in a plain text document is
|> by using two spaces instead of one. This is what I'm consistently
|> doing, no matter in which of the three languages I'm familiar with
|> I'm writing.

Then you're probably doing it wrong in two of them. Different
linguistic communities have different conventions. A larger space after
a sentence is definitly wrong in French or German, and I think it is
wrong in Italian. On the other hand, it would generally be considered
poor typesetting in English not to use it, although how much extra space
is debattable, and if the difference is small enough, the average reader
might miss it.

|> >Now the French, they put a space before an exclamation or question
|> >mark. Like this: "Regardez moi ! Je suis français !". What's
|> >with that, then?

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

On the other hand, correct typographical use here is an espace fine
insécable, not a full space. Personally, I find the difference
between an espace fine and an espace mots pretty small, and when using a
fixed width font, use a normal espace for both. I know people, however,
who insist on the difference, and drop the espace fine, rather than use
a full space. (They're the exceptions, I think, but I've not done a
statistical analysis to prove it.)

In C, I've noticed that it is immediately obvious when a French speaker
has written the code, even if the comments are in English -- there's a
space in front of the : and the ;, which is never present in code
written by anyone else.

--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France [phone]

[Mark McIntyre]

On 29 May 2004 11:42:44 +0200, in comp.lang.c , James Kanze
<ka***@gabi-soft.fr> wrote:

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

|> In <c9**********@oravannahka.helsinki.fi> Joona I Palaste
|> <pa*****@cc.helsinki.fi> writes:

|> >Now the French, they put a space before an exclamation or question
|> >mark. Like this: "Regardez moi ! Je suis français !". What's
|> >with that, then?

|> 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....
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[Viktor Lofgren]

In comp.lang.c C# Learner <cs****@learner.here> wrote:

Alex Moskalyuk wrote:

Have you ever looked into Perl or Lisp code?

C suddenly starts making perfect sense.

What's uneasy to you? Curly braces, parentheses, keywords, or something
else?
One of the biggest flaws in C syntax, in my opinion, is the required
parentheses for test conditions.

Here's a very simple example:

void Foo
{
if (FooBar(Parse(Process(GetInput())))
DoSomething();
}

That is _very_ bad code. What if Parse, Process or GetInput fails,
how would you know what hit you?

Instead,
void Foo(void)
{
type_t a;
if(!(a=get_input()))
puts("GetInput died");
if(!(a=process(a)))
puts("process died");
if(!(a=parse(parse())
puts("Parse died");
if(foobar(a)
do_something();
}
Imagine if, instead, we could write the following:

void Foo
{
if FooBar(Parse(Process(GetInput())):
DoSomething();
}
This is why: it would not be consistant with the C code-style. The
style is in fact is very obvious when properly idented and highligthed,
Another nicety about Python is the fact that whitespace is used for
defining code blocks. This makes code much clearer than the equivalent
C code, which requires block being/end markers.
I don't like the idea of having indentation as a part of the syntax,
very hard to write longer code on 80x25 terminals :-(
Even if one's accustomed to C syntax, the former is still clearer and
easier-to-read, don't you think?
Programming languages are not meant to be easy to read.
If you want easy-to-read, comment your code.
Why C? Why?!

Here's why: It works and is perfectly balanced between levels. It is not
gibberish like LISP or Assembly (no offense, but it is kinda hard to see what
(+ 2 (* 8 (expt 25 (/ 5 2)))) does). And you still consistent (unlike BASIC)
and doesent require you to write a smaller novel (unlike COBOL) to get your
app to do something. Python may be an OK language, but it still doesent
have the maturity of C.

--
Viktor Lofgren, Umea, Sweden
Mainly self-eductated UNIX programmer, running Slackware-current.

[CBFalconer]

Viktor Lofgren wrote:

Learner <cs****@learner.here> wrote:

Alex Moskalyuk wrote:

Have you ever looked into Perl or Lisp code?

C suddenly starts making perfect sense.

What's uneasy to you? Curly braces, parentheses, keywords, or
something else?

One of the biggest flaws in C syntax, in my opinion, is the
required parentheses for test conditions.

Here's a very simple example:

void Foo
{
if (FooBar(Parse(Process(GetInput())))
DoSomething();
}

That is _very_ bad code. What if Parse, Process or GetInput
fails, how would you know what hit you?

Instead,
void Foo(void)
{
type_t a;
if(!(a=get_input()))
puts("GetInput died");
if(!(a=process(a)))
puts("process died");
if(!(a=parse(parse())
puts("Parse died");
if(foobar(a)
do_something();
}

That is still foul and faulty code. Assuming there is an error
value 0, try:

void Foo(void)
{
type_t a;

if (!(a = get_input())) puts("GetInput died");
else if (!(a = process(a))) puts("process died");
else if (!(a = parse(a()) puts("Parse died");
else if (foobar(a) do_something();
/* else donothing */
}

If there is no such error value, the original is much clearer.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Arthur J. O'Dwyer]

On Sat, 29 May 2004, Viktor Lofgren wrote:

In comp.lang.c C# Learner <cs****@learner.here> wrote:

if (FooBar(Parse(Process(GetInput())))
DoSomething();
That is _very_ bad code. What if Parse, Process or GetInput fails,
how would you know what hit you?

<on-topic for once> This is the general argument in favor of
writing fail-immune functions. For example, if 'GetInput' fails
it will (let's say) return NULL. Now, 'Process' knows that it
will be very tempting for the client to write 'Process(GetInput())';
thus, 'Process' codes as follows:

void *Process(const void *input)
{
if (input == NULL) return NULL;
[...]
}

Now 'Process' can handle anything 'GetInput' throws at it, and it
can do it in a reasonable manner. Apply the same solution to
'Parse' and 'FooBar'. Now the client can safely write

if (FooBar(Parse(Process(GetInput())))
DoSomething();
else
/* Something went wrong in one of those four functions */
;

This is a nice idiom to learn and use; unfortunately, the C
standard library doesn't use it in most places. Especially in
'strcpy' it would be convenient, so that

#define stdup(s) (strcpy(malloc(strlen(s)+1), (s)))

wouldn't exhibit undefined behavior if 'malloc' were to fail,
but sensibly return NULL.
[Not that I'm advocating a change to 'strcpy'; just pointing
out one of the disadvantages of a model that *doesn't* use the
fail-immune handling shown above.]
<back off-topic>
I don't like the idea of having indentation as a part of the syntax,
very hard to write longer code on 80x25 terminals :-(

The canonical solution applies here: If your lines are too long
to be read comfortably by the average human, you ought to be writing
shorter lines. And/or smaller functions with fewer levels of
indentation.

Even if one's accustomed to C syntax, the former is still clearer and
easier-to-read, don't you think?

Programming languages are not meant to be easy to read.
If you want easy-to-read, comment your code.

Don't be ridiculous! Languages are *by definition* meant to make
communication simpler. And until computers learn to talk properly,
that communication is only going to happen through reading. C's
syntax, like that of every (non-joke) language in existence, was
designed to make reading and writing as easy, pleasurable and
effective as possible. The fact that some people like to write
impenetrable C code is no stranger than that some people like to
write impenetrable English or French.

-Arthur

[Dr Chaos]

On Wed, 26 May 2004 22:02:42 +0100, C# Learner <cs****@learner.here> wrote:

Why is C syntax so uneasy on the eye?

In its day, was it _really_ designed by snobby programmers to scare away
potential "n00bs"?
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. And it was in the days where actually printing
programs and typing them in was physically expensive and difficult
(literal paper-oriented terminals and tty inputs). So severely
limiting characters was a desirable major goal then. It isn't now.
If so, and after 50+ years of programming research,
why are programming languages still being designed with C's syntax?
Profound anti-intellectualism among practitioners, and cargo-cult
imitation. This spurious idea being that "gee, C was popular; so why
don't we make our language with Cish syntax so we might be popular
too."

Yes, these things have been tested empirically (though that field
is woefully underfunded) and yes the answer comes back that other
syntaxes are less error prone.

In particular the Fortran 90 and Ada typical syntaxes come out on
top.
These questions drive me insane. Every waking minute...

The answers are easy. But depressing.

[Malcolm]

"Dr Chaos" <mb****************@NOSPAMyahoo.com> wrote in message

Profound anti-intellectualism among practitioners, and cargo-cult
imitation. This spurious idea being that "gee, C was popular; so
why don't we make our language with Cish syntax so we might be
popular too."

Or maybe "C is popular so let's use a syntax that most programmers are
already familiar with".
Just as sensible as using English language keywords and function names,
because most programmers already know at least some English.

[August Derleth]

On Fri, 28 May 2004 11:13:43 +0400, Dmitry Zamotkin wrote:

he-he.
C is not functional too.
Try rand() function.

rand() works right. You are broken.

--
yvoregnevna gjragl-guerr gjb-gubhfnaq guerr ng lnubb qbg pbz
To email me, rot13 and convert spelled-out numbers to numeric form.
"Makes hackers smile" makes hackers smile.

[red floyd]

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.

[C# Learner]

[Note: I was unable to post a message to comp.lang.c (as specified in
the "Followup-To" header in your message) unless I also posted to
microsoft.public.dotnet.languages.csharp. I'm not certain why. In any
case, I've restored that "Followup-To" header.]

Dr Chaos wrote:

<snipped some interesting stuff>

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

The answers are easy. But depressing.

I'm glad you understand. :-)

[I. Appel]

"August Derleth" <se*@sig.now> wrote in message
news:pa****************************@sig.now...

he-he.
C is not functional too.
Try rand() function.

rand() works right. You are broken.

Actually, rand() has some side-effects - changing the seeds of pseudo-random
generator.
So, such function is not pure-fuctional-programming-language-function.

[I. Appel]

"August Derleth" <se*@sig.now> wrote in message
news:pa****************************@sig.now...

he-he.
C is not functional too.
Try rand() function.

rand() works right. You are broken.

Actually, rand() has some side-effects - changing the seeds of pseudo-random
generator.
So, such function is not pure-fuctional-programming-language-function.

[I. Appel]

"Viktor Lofgren" <zw*@eudial.nos--pam.mine.nu> wrote in message
news:tk****************@newsb.telia.net...

Here's why: It works and is perfectly balanced between levels. It is not
gibberish like LISP or Assembly (no offense, but it is kinda hard to see what (+ 2 (* 8 (expt 25 (/ 5 2)))) does).

To start understand such stuff you need to write code in LISP for a few
days, not more. After that it may become even _simpler_ to understand,
because it's not required to memorize order of precedence.

[Dr Chaos]

Malcolm <ma*****@55bank.freeserve.co.uk> wrote:

"Dr Chaos" <mb****************@NOSPAMyahoo.com> wrote in message

Profound anti-intellectualism among practitioners, and cargo-cult
imitation. This spurious idea being that "gee, C was popular; so
why don't we make our language with Cish syntax so we might be
popular too."
Or maybe "C is popular so let's use a syntax that most programmers are
already familiar with".

Actually I think that's can be a worse idea---suggesting something
that 'almost works' the same, but in fact is subtly different is quite
dangerous.

Like, in the USA you might want to give your buddy who's had too much
to drink "a ride" home, but if you try offer that to your mates in
Sydney (as opposed to a "lift") you're likely to get socked. At least
in most straight bars.
Just as sensible as using English language keywords and function names,
because most programmers already know at least some English.

It is not as sensible, especially when other forms are tested to be
better.

I believe natural language is an different situation because human
brains have specific circuits for it, and not specifically programming
languages.

To some degree (but not completely) good syntaxes are those which can
use the low-level processing of brains and natural langauges to suggest
the correct semantics "without thinking", or at least the conscious
perception thereof.

For instance, Lisp has practically no syntax, but that doesn't make
it easy---it offloads all understanding to the general conscious processing
of the cortex. And linguistic testing has shown that humans do not
have that deep a mental stack.

So despite the fact that from a purely theoretical perspective, Lisp
programs should be very easy to understand, they aren't, and
programming languages with more redundant and full syntaxes seem to be
generally preferred. Lisp has advantages that can outweigh
its disadvantages, but non-ergonomic syntax is a disadvantage.
(Smalltalk may share some of this as well). Lisp is a bad syntax
but it can be worth it. I don't think C-derived syntaxes are.

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

[Dr Chaos]

Arthur J. O'Dwyer <aj*@nospam.andrew.cmu.edu> wrote:

Not that I'm disagreeing, but *is* there any ambiguity avoided
by requiring parens around the condition in a 'do...while' loop?
I don't know about C, but it may have been a holdover from Fortran,
where it does matter:

! fortran
if (condition = something) then

because
if condition = something

can be also

ifcondition = something

an assignment.

In C I don't see the issue, I admit.
E.g., what problem, if any (besides lack of symmetry), is introduced
by the "reform"

do stmt; while expr;
do { block } while expr;

replacing

do stmt; while (expr);
do { block } while (expr);

(Also, there's no ambiguity avoided by the requirement of a semicolon
following the label of a 'goto'. Just defusing potential "do you
know you're being utterly ridiculous" responses. ;)

-Arthur

[ozbear]

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.

Oz
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?