our friend "{"

[stephen@alberta]

The original reason for the following definitions was that my
first ever C program was written on an IBM machine where the
squirley braces were quite the pain to use and where the C
compiler refuses to work.
Since I wasn't all to sure where the problem was, I wrote the
program using ALGOL/68 constructs and put in the #defines with
what I thought were the corret formats and passed the program to
a friend on the VAX (which I didn't have access to at the time).
Once I got onto UNIX, I found that the constructs served to
minimize syntax errors and make my programs easier to read.

The main problem with the constructs is that they are not
understood by "emacs", "cb" etc..
-------------------------------------------------------------

#define begin {
#define end }

#define IF if(
#define THEN ){
#define ELSE } else {
#define ELIF } else IF
#define FI }

#define FOR for(
#define WHILE while(
#define DO ){
#define OD }

#define LOOP do{
#define UNTIL } while(
#define DONE );

#define SWITCH switch(
#define IN ){
#define CASE ;break ;case
#define DEFAULT ;break ; default
#define OUT }

#define FOREACH(PARC,PARV,COUNT)\
for(COUNT = (PARC > 1 ? 0 : --PARV, -1) ; ++COUNT == 0 | (++PARV, --PARC > 0 ; )\

#ifndef DO
#define DO ){
#define OD }
#endif

#define PARNUM(NUM,PARV,COUNT) (PARV+NUM-COUNT)
#define FORNEXT(PARC,PARV,COUNT) (++COUNT, ++PARV, --PARC)
/* PARNUM returns the NUM'th par. FORNEXT moves to the next par */

-----------------------------------------------------------------

FOREACH was defined to help handle shell pars with a minimum
of fuss. PARC and PARV are (copies of) the values passed by the
shell and COUNT is used to indicate which par is presently
"active" (COUNT==0 indicates no pars).

Stephen Samuel(alberta!stephen)

[sil...@csu-cs.uucp]

The freedom to redefine the language with macros is also the freedom to
rotate your vocabulary out of the public domain, right into the twilight
zone. Personally, I view people who alter C to suit their personal
tastes as certainly misguided and probably perverted. Any standard is
better than none (stick that in your fortunes file and remember it); I'd
rather live with C than "improve" it unilaterally.

Sorry for the outburst, but I feel the urge to counter the previous
article, which seemed to espouse such gimmickry as a good idea.

Alan Silverstein, Hewlett-Packard Fort Collins Systems Division, Colorado
ucbvax!hplabs!hpfcla!ajs, 303-226-3800 x3053, N 40 31'31" W 105 00'43"