PROS/CONS: #define BEGIN {

[Mike Malone]

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.

My initial reaction is "Yuck!" (Not too different from the FAQ, which just
says "Bleah").

Aside from that, what are some good reasons to do this, or not to do this?
A few negatives I come up with include:

* Won't work with some tools, such as
- syntax-aware editors
- metrics
- static analysis tools
- coding style enforcement
- code indenters/reformatters
- pretty printers

* Does not check for mismatches (e.g., "{" vs. "END").

* Does not prevent use of {, }, ==, etc., just adds alternatives.

* Requires re-training of C developers who are used to standard C syntax.

[Kevin D. Quitt]

Why not go all the way? With a little cleverness, you could have BASIC.
--
#include <standard.discl aimer>
_
Kevin D Quitt USA 91387-4454 96.37% of all statistics are made up
Per the FCA, this address may not be added to any commercial mail list

[Dan Pop]

In <dY************ ******@newssvr1 9.news.prodigy. com> "Mike Malone" <mr*@prodigy.ne t> writes:

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.

My initial reaction is "Yuck!" (Not too different from the FAQ, which just
says "Bleah").

Aside from that, what are some good reasons to do this, or not to do this?

ANY usage of the C preprocessor that messes with the language syntax
should be avoided, unless the redeeming benefits are great enough to
compensate for the loss in program readability. And this kind of silly
substitutions have exactly zilch redeeming benefits.

Apparently, the original implementation of the Bourne shell was made
using a header file named "algol.h", whose purpose should be obvious
from its name. The end result was that no one wanted to maintain that
program, so it had to be retranslated to proper C.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union

[E. Robert Tisdale]

Bart wrote:

Peter Hickman wrote:

converts this:

if(x == 1) {
puts("The value is 1");
}

into this:

IF x eq 1 THEN BEGIN
puts("The value is 1");
END

They will produce the same output but the punctuation now takes up much more space.
Proper English words are, in my opinion,
more readable than lots of punctuation,
even if it takes more space
and C does seem to have far too many unnecessary symbols,
such as semicolons.

The C syntax looks like something
that was hastily knocked up one afternoon
and nobody has updated it since.

It certainly was *not*.
It was very carefully crafted
to take advantage of the ASCII character set
and to minimize the number of keystrokes
which you would realize was a very important consideration
if you had ever tried to program at a teletype terminal.
However that *is* the C language and most seem happy with it.

Tinkering with bits of syntax using DEFINEs
is likely to be unsatisfactory;
the above example seems a mix of FORTRAN, PASCAL and C.

Either use a different language
or a formal language extension that uses software
to convert your favorite syntax into standard C (my pet project).

I agree that the C preprocessor
is a poor language translation tool.

[Bart]

On Wed, 15 Dec 2004 00:05:18 +0100, "KiLVaiDeN"
<Ki*******@CaRa MaiL.CoM> wrote:

"Bart" wrote...

Proper English words are in my opinion more readable than lots of
punctuation, even if it takes more space, and C does seem to have far
too many unnecessary symbols, such as semicolons.

I think it'd be very annoying after a while to see tons of "BEGIN"
everywhere on the code..

Imagine something like ( useless code ) :

while(true)
{
do_something();
if(something is true)
{
do_something_el se();
increment_somet hing();
}
else
{
decrement_somet hing();
do_nothing();
}
}

Would translate into something like :

while(true)
BEGIN
do_something();
if(something is true)
BEGIN
do_something_el se();
increment_somet hing();
END
else
BEGIN
decrement_somet hing();
do_nothing();
END
END

Really the first one looks more readable to me !

I admit I'm not a fan of 'begin', I would code your fragment as
something like (loosely taken from Algol68):

do
do_something
if something then
do_something_el se
increment_somet hing
else
decrement_somet hing
do_nothing
endif
end

The original C has:

5 extra semicolons (perhaps one more after final } needed?)
5 extra lots of () for functions
1 () pair for the 'if'
2 extra {, the other replaced by 'then'
1 extra } just before 'else', the others replaced by 'endif'/'end'
1 () pair around 'true' ('while true' is redundant, 'do' will start an
endless loop)

As I said in my original post, lots of unnecessary punctuation in C,
perhaps 20 symbols in this short fragment, without which the code
looks much cleaner, especially printed with bold keywords.

As for extra typing, the original C source had some 177 bytes, my code
about 143 bytes (without 'while true'), and with endif/end removed,
python-like, as they could be made redundant, would be about 130 bytes
(all using tabs not spaces).

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.

[dandelion]

"Bart" <48**@freeuk.co m> wrote in message
news:61******** *************** *********@4ax.c om...

<snip>

5 extra semicolons (perhaps one more after final } needed?)
5 extra lots of () for functions
1 () pair for the 'if'
2 extra {, the other replaced by 'then'
1 extra } just before 'else', the others replaced by 'endif'/'end'
1 () pair around 'true' ('while true' is redundant, 'do' will start an
endless loop)
You seem to be of the opinion that the "extra" punctuation is a bad point.
I, for one, do not think of it as such.

For instance, the language you use omits '(' and ')' for function names, but
i do not suppose that this is also the case when you want to apply a few
parameters. Furthermore, in 'C'

int foobar(void);

int some_var = foobar();

is something completely different than

int foobar(void);

some_var = foobar;

This difference does not seem to be translated into your language. It also
shows that at least some of the parenthesis aren't "unnecessar y".
As I said in my original post, lots of unnecessary punctuation in C,
perhaps 20 symbols in this short fragment, without which the code
looks much cleaner, especially printed with bold keywords.
Ah... A matter of taste. Well, tastes differ.
As for extra typing, the original C source had some 177 bytes, my code
about 143 bytes (without 'while true'), and with endif/end removed,
python-like, as they could be made redundant, would be about 130 bytes
(all using tabs not spaces).
Using tabs do to indenting is a *very* bad idea. I've seen more source that
looked like garbage (but wasn't) due to this. As an aside, i could not care
less about a few extra bytes of *source* code. A few extra bytes of *object*
code may keep me awake at night, though.
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.

Well, at least you did not convince me.

[Lawrence Kirby]

On Tue, 14 Dec 2004 22:43:36 +0000, Bart wrote:

On Tue, 14 Dec 2004 10:05:06 +0000, Peter Hickman
<pe***@semantic o.com> wrote:

converts this:

if(x == 1) {
puts("The value is 1");
}

into this:

IF x eq 1 THEN
BEGIN
puts("The value is 1");
END

They will produce the same output but the punctuation now takes up much more space.

Proper English words are in my opinion more readable than lots of
punctuation, even if it takes more space, and C does seem to have far
too many unnecessary symbols, such as semicolons.

Where are C's semicolons unnecessary? Even Pascal uses them in a similar
way. The main difference in (imperative) languages are those that treat
end of line as a terminator. This has its own drawbacks and later
(imperative) languages tend to avoid it. If you don't do that you need
something to act as a separator/terminator.
The C syntax looks like something that was hastily knocked up one
afternoon and nobody has updated it since.
Well I might agree with you on that concerning the switch statement. :-)
However that *is* the C language and most seem happy with it.

We do recognise that there are things that could be designed better in C,
like operator precedence and integral promotions. Many people bemoan
declaration syntax. But the basic syntax and symbology of statements and
operators works pretty well, and it is hard to find anything that doesn't
serve a purpose. E.g. consider

if (isupper(ch)) *p = ch;

Take those ()'s for the if away and you get

if isupper(ch)*p = ch;

which isn't the same thing, or would be hard to parse consistently as the
same thing in the general case.

Lawrence

[Bart]

On Wed, 15 Dec 2004 12:46:56 +0100, "dandelion" <da*******@mead ow.net>
wrote:

int some_var = foobar(); ....some_var = foobar; This difference does not seem to be translated into your language. It also
shows that at least some of the parenthesis aren't "unnecessar y".
some_var=foobar presumably takes the address of the function, which is
probably better written explicitly as some_var=&fooba r.

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.

....Ah... A matter of taste. Well, tastes differ.

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

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.

Bart

[dandelion]

"Bart" <48**@freeuk.co m> wrote in message
news:9q******** *************** *********@4ax.c om...

On Wed, 15 Dec 2004 12:46:56 +0100, "dandelion" <da*******@mead ow.net>
wrote:

int some_var = foobar(); ...

some_var = foobar;

This difference does not seem to be translated into your language. It alsoshows that at least some of the parenthesis aren't "unnecessar y".

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

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.

Ah... A matter of taste. Well, tastes differ.

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]

"dandelion" <da*******@mead ow.net> wrote:

"Bart" <48**@freeuk.co m> wrote in message
news:9q******** *************** *********@4ax.c om...

On Wed, 15 Dec 2004 12:46:56 +0100, "dandelion" <da*******@mead ow.net>
wrote:

int some_var = foobar(); ...

some_var = foobar;
That isn't legal as it stands. You cannot assign a pointer to an int
without a cast.
This difference does not seem to be translated into your language. It also
shows that at least some of the parenthesis aren't "unnecessar y".

some_var=foobar presumably takes the address of the function, which is
probably better written explicitly as some_var=&fooba r.
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.

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.
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.
I must spend half my time playing pendantics with my compiler instead of
developing my application.

Strange. I don't.

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

Ah... A matter of taste. Well, tastes differ.

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.

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]

"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message

<snip>

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.

:-( *Bad*.

<snip>

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.

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

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

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

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

Strange. I don't.

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

>Ah... A matter of taste. Well, tastes differ.

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.

Not true.

Gimme a break!
<snip>
(* 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 (,).