PROS/CONS: #define BEGIN {

[dandelion]

some_var=foobar presumably takes the address of the function, which is
probably better written explicitly as some_var=&foobar.

That would give me a pointer-to-a-pointer-to-a-function.

http://www.eskimo.com/~scs/C-faq/q1.34.html

You must admit C does have an awful lot of semicolons: perhaps 90% or
more associated with end-of-line (EOL) yet typing EOL is not enough, I
must also type ;, because a few statements take more than one line.

And I can have as many statements on a line as I wan't to. Not that I
generally
do that, but we *are* talking about 'C', which allows it. Hence the
semicolon.

Besides, 'end of line' is code '0x0A' on some systems, '0x0A, 0x0D' on
others
and a third variety does it using '0x0D'. Using your preference, a (say)
Unix
source cannot compile on a (say) Macintosh and neither will compile on a
Windblows machine.

And to top the bill, I like to leave white-lines between blocks of code to
improve readability. I frequently chop up looooooooong calls into separate
lines for the same reason, and do the same with lenngthy versions of
conditions in if(), while() and friend. Those extra newlines (excusez le
mot) would be part of the language in your setup.

I would not like that. And that's putting it (very) mildly.

I must spend half my time playing pendantics with my compiler instead of
developing my application.

Strange. I don't.

Yes, of course. The OP's colleague presumably had migrated from PASCAL
or wherever and couldn't cope with all the {,} in C (I think in
PASCAL these are comment symbols!).

Nope. that '(*' and '*)', IIRC.

It is highly unlikely ISO C will change it's syntax for my benefit or
for others (although syntax is so easy to change), so I guess I will
soon have to be writing raw C as well.

So get used to it or choose another language. There's enough of them around.
Alternative: grab the gcc sources and add a front-end. Then see how popular
it gets.

 

[Richard Bos]

That isn't legal as it stands. You cannot assign a pointer to an int
without a cast.

This is a matter of taste.

That would give me a pointer-to-a-pointer-to-a-function.

No, it wouldn't. Either way takes the address of a function. Strictly
speaking, only &function would be correct, but since there's nothing you
can do with a function except call it or take its address, the ampersand
has been made optional.

If you want BASIC, you know where to find it. It may come as a surprise
to you, btw, that in C statements can span several lines. I don't know
about you, but I find this a very useful feature.

And I can have as many statements on a line as I wan't to.

That, too, but that's not the reason why the last statement on a line
must end in a semi-colon.

Besides, 'end of line' is code '0x0A' on some systems, '0x0A, 0x0D' on
others and a third variety does it using '0x0D'.

Non sequitur. This is as true for preprocessor statements now as it
would be for normal statements, and that has never been a problem.

Strange. I don't.

Neither do I. Perhaps Bart should spend more time learning the language
and less time griping about it.

Nope. that '(*' and '*)', IIRC.

Not true. { and } are the original comment delimiters in Pascal (it's
Pascal, btw, not PASCAL; it's named after Blaise P., not an acronym); (*
and *) were introduced (no idea at what time) for the sake of systems
which don't have { and } in their charset, much as ??< and ??> (and now
<% and %>) in C.

Richard

 

[dandelion]

No, it wouldn't. Either way takes the address of a function. Strictly
speaking, only &function would be correct, but since there's nothing you
can do with a function except call it or take its address, the ampersand
has been made optional.

:-( *Bad*.

That, too, but that's not the reason why the last statement on a line
must end in a semi-colon.

And all the other statements do not have to? Wow. That's new.

Non sequitur.

I wasn't making any conclusions from it , I merely point it out. And no, it
would not be a major problem, but it would need to be specified. Besides,
the C-syntax is rather a far cry form the CPP syntax.

This is as true for preprocessor statements now as it
would be for normal statements, and that has never been a problem.

So *this* is the Non Sequitur. If something isn't a problem in Prolog, it
may *well* be a problem in Lisp.

I notice you snip the most important reason for not having 'newline' as a
statement delimiter without marking snippage. Unmarked snippage is
considered bad form on many froups.

May be construed as telling less than the whole thruth...

Neither do I. Perhaps Bart should spend more time learning the language
and less time griping about it.


Not true.

Gimme a break!

(* and *) were introduced (no idea at what time) for the sake of systems
which don't have { and } in their charset

So '(*' and '*)' mark comment. Thanks.

To Bart i'll admit i misread {,} for (,).

 

[Chris Croughton]

You must admit C does have an awful lot of semicolons: perhaps 90% or
more associated with end-of-line (EOL) yet typing EOL is not enough, I
must also type ;, because a few statements take more than one line.

In real code a lot of statements take more than a line (at least with
reasonable line lengths). Typing semicolon is one character per
statement, having to add \ at the end of lines (and take them out) or
some other continuation character is a lot more painful. As is typing
BEGIN and END (and THEN and ENDIF for statements which don't need them).

I
must spend half my time playing pendantics with my compiler instead of
developing my application.

Then you should learn to write C. I very rarely have a semicolon
missing from a statement when I program in C. Yes, it's annoying when
the compiler flags some silly error, but it's a lot more expensive if it
just assumes that you meant whatever it was

It is highly unlikely ISO C will change it's syntax for my benefit or
for others (although syntax is so easy to change),

Syntax is not at all easy to change. Have you ever written a compiler?
Would you like to have to change millions of lines of existing code
because someone wants to change the syntax (and debug it, and verify
it...)?

so I guess I will
soon have to be writing raw C as well.

Indeed. Or you could get Visual Basic...

Chris C

 

[Lawrence Kirby]

some_var=foobar presumably takes the address of the function, which is
probably better written explicitly as some_var=&foobar.

Yes, you could do that. However when I see

some_var = foobar();

I know that foobar() is a function call. When I see

some_var = foobar;

that wouldn't be obvious at all. Having used languages like Pascal (indeed
before I started using C) it is my considered opinion that C's approach is
simply better in this respect.

You must admit C does have an awful lot of semicolons: perhaps 90% or
more associated with end-of-line (EOL) yet typing EOL is not enough, I
must also type ;, because a few statements take more than one line. I
must spend half my time playing pendantics with my compiler instead of
developing my application.

I haven't found typing one extra character per line a great hardship. The
more significant question is whether this syntax aids readability, which
is harder to say. Most languages I've used that don't do this have been
text processing or scripting languages and comparing readability between
such different languages, and how much of that is down to ; isn't easy. I
think code using ; is more consistent, especially in languages that try to
"guess" whether a 2nd line is a continuation or a new statement/command.

Lawrence

 

[john_bode]

Of course I'm not expecting to persuade anyone reading comp.lang.c
that C syntax is anything other than wonderful... just a few
observations.

Bart.

It's not that C syntax is so wonderful (it really, really isn't); it's
that using the preprocessor to redefine the language *always* leads to
heartburn. The OP's negative points are spot on. It breaks
language-sensitive tools; it requires retraining; it will lead to
maintenance headaches as the language changes over time.

If you don't like C syntax, USE A DIFFERENT LANGUAGE. There are plenty
to choose from.

 

[Keith Thompson]

That would give me a pointer-to-a-pointer-to-a-function.

http://www.eskimo.com/~scs/C-faq/q1.34.html

No, it doesn't (and the FAQ doesn't say it does). A function name in
an expression decays to a pointer-to-function *unless* it's the
operand of "&" or "sizeof" (the latter case is a constraint
violation).

And I can have as many statements on a line as I wan't to. Not that
I generally do that, but we *are* talking about 'C', which allows
it. Hence the semicolon.

If C banned multiple statements per line, it would be no great loss in
my opinion (except, of course, that it would break tons of existing
code). The real issue is multi-line statements. Most C programmers,
I think, type the trailing ';' without thinking about it, and barely
notice it when reading code.

Besides, 'end of line' is code '0x0A' on some systems, '0x0A, 0x0D'
on others and a third variety does it using '0x0D'. Using your
preference, a (say) Unix source cannot compile on a (say) Macintosh
and neither will compile on a Windblows machine.

Irrelevant. Any source file has to be converted when it's transferred
from one system to another. Some compilers may tolerate, e.g., CR-LF
pairs on a Unix system, or LF line terminators on a Windows system,
but in general if the text file formats differ you have to translate.

And to top the bill, I like to leave white-lines between blocks of code to
improve readability. I frequently chop up looooooooong calls into separate
lines for the same reason, and do the same with lenngthy versions of
conditions in if(), while() and friend. Those extra newlines (excusez le
mot) would be part of the language in your setup.

I would not like that. And that's putting it (very) mildly.

If a C-like language used end-of-line rather than semicolon to delimit
statements and declarations, presumably it would be designed to permit
arbitrary blank lines. (I think Python does this.)

[snip]

 

[Bart]

If you don't like C syntax, USE A DIFFERENT LANGUAGE. There are plenty
to choose from.

Not so many. Some people like the low-level, machine-oriented
semantics of C, where you can usually double-guess what the compiler
will do, but are not so keen on the look and feel. And other
considerations may require the use of C.

Perhaps the syntax of a language should be separate from the rest of
it, like a 'skin' that can be chosen according to preference. That
would be something..

Bart

 

[dandelion]

If a C-like language used end-of-line rather than semicolon to delimit
statements and declarations, presumably it would be designed to permit
arbitrary blank lines. (I think Python does this.)

That does not address the point of breaking up long statements into multiple
lines for readability.

<snip>

 

[dandelion]

Not so many. Some people like the low-level, machine-oriented
semantics of C, where you can usually double-guess what the compiler
will do, but are not so keen on the look and feel. And other
considerations may require the use of C.

Perhaps the syntax of a language should be separate from the rest of
it, like a 'skin' that can be chosen according to preference. That
would be something..

Checkout http://gcc.gnu.org

You may not be the first with that idea.

 

[Keith Thompson]

That does not address the point of breaking up long statements into
multiple lines for readability.

No, it doesn't. Since I don't think it's a good idea, I wasn't going
to work out all the details.

But I suppose the most obvious thing to do would be to use '\' as a
continuation character.

 

[Richard Bos]

Yes, you could do that. However when I see

some_var = foobar();

I know that foobar() is a function call. When I see

some_var = foobar;

that wouldn't be obvious at all. Having used languages like Pascal (indeed
before I started using C) it is my considered opinion that C's approach is
simply better in this respect.

It's even worse in Pascal, because it does allow the name to occur, as a
normal identifier, on the left side of an assignment (where it
represents the return value); this makes it easy to assume, erroneously,
that it _is_ a normal identifier, and can be used on the right side as
well.

Richard

 

[Lawrence Kirby]

On Thu, 16 Dec 2004 10:47:08 +0000, Keith Thompson wrote:

....

But I suppose the most obvious thing to do would be to use '\' as a
continuation character.

You can do that, some languages do and even some data file formats. For
human edited data like source code it has IMO proved to be a VERY
error-prone mechanism.

Of course C has this mechanism which can be used anywhere but isn't needed
except for multi-line macro definitions and the old method of multi-line
string literals. IMO it is only the fact that the need to use it is rare
that makes it tolerable. It would be grim indeed if you had to use it for
every multi-line statement.

Lawrence

 

[dandelion]

No, it doesn't. Since I don't think it's a good idea, I wasn't going
to work out all the details.

But I suppose the most obvious thing to do would be to use '\' as a
continuation character.

Considering the amounts of time i've wasted correcting missing or
superfluous '/' i do not think that's a great idea.

 

[Bart C]

Of course C has this mechanism which can be used anywhere but isn't needed
except for multi-line macro definitions and the old method of multi-line
string literals. IMO it is only the fact that the need to use it is rare
that makes it tolerable. It would be grim indeed if you had to use it for
every multi-line statement.

EOL processing can be made fairly painless. An EOL (carriage return) is
quite different from a mere space and it would be a shame for the compiler
to completely ignore this extra *information* in a source file.

For example EOL can be ignored when following a symbol that is *expected* to
be followed by something else, such as "+". And converted to ";" (or acts as
statement terminator) otherwise. Use "\" to override this behaviour in the
latter case and ";" in the former, if it should ever be necessary.

Some conventions need to be used, for example it is necessary, if splitting
'a+b', to write:

a+
b

rather than:

a
+ b

In practice multiple EOLs (blank lines) must be treated as one and the
compiler should be tolerant of consecutive ";"s. The biggest problem (I will
mention it before anyone else) is sending source code over networks that
wrap lines at arbitrary points.

Bart.

 

[Lawrence Kirby]

On Thu, 16 Dec 2004 17:20:02 +0000, Bart C wrote:

....

EOL processing can be made fairly painless. An EOL (carriage return) is
quite different from a mere space and it would be a shame for the compiler
to completely ignore this extra *information* in a source file.

For example EOL can be ignored when following a symbol that is
*expected* to be followed by something else, such as "+". And converted
to ";" (or acts as statement terminator) otherwise. Use "\" to override
this behaviour in the latter case and ";" in the former, if it should
ever be necessary.

The problem isn't how the compiler handles this, it is with the
readability and maintainability of source code that results from this.
I've experienced it, and I wouldn't call it good.

Some conventions need to be used, for example it is necessary, if
splitting 'a+b', to write:

a+
b

rather than:

a
+ b

Languages like AWK do this sort of thing which is OK for that, but I still
find having explicit end of statement markers that I can locate instantly
more readable.

In practice multiple EOLs (blank lines) must be treated as one and the
compiler should be tolerant of consecutive ";"s. The biggest problem (I
will mention it before anyone else) is sending source code over networks
that wrap lines at arbitrary points.

That can affect C as it is, notably with string literals and now that C99
supports // style comments. Although problems with those are usually easy
to spot and fix.

Lawrence

 

[Sniper1]

You can do that, some languages do and even some data file formats. For
human edited data like source code it has IMO proved to be a VERY
error-prone mechanism.

Which is precisely why we now have widescreen monitors, variable
font sizes, editors that can handle more than 80 columns and
landscape printers.

If you need really long lines, a dual-monitor video card can be
employed.

Is a smiley required?

 

[Charlie Gordon]

A colleague of mine is proposing that we use a set of preprocessor
definitions to make our C code more readable:

#define BEGIN {
#define ENG }
#define EQ ==
etc.

This will considerably reduce code readability.
So much so that (almost) no one noticed the typo on ENG
Your colleague is teasing you, or begging to be fired.

 

[CBFalconer]

(e-mail address removed) says...


Which is precisely why we now have widescreen monitors, variable
font sizes, editors that can handle more than 80 columns and
landscape printers.

If you need really long lines, a dual-monitor video card can be
employed.

Or other ugly things, none of which beyond a 72 char wide text line
should be necessary. Even C has no need for a line continuation
character outside of specifying macros. Even here a simple syntax
change should suffice, something like BEGINMACRO .... ENDMACRO.

 

[Richard Bos]

For example EOL can be ignored when following a symbol that is *expected* to
be followed by something else, such as "+". And converted to ";" (or acts as
statement terminator) otherwise. Use "\" to override this behaviour in the
latter case and ";" in the former, if it should ever be necessary.

Some conventions need to be used, for example it is necessary, if splitting
'a+b', to write:

a+
b

rather than:

a
+ b

Blech. If you want Icon, you know where to find it.

Richard