stephen@alberta (08/03/83)
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)silver@csu-cs.UUCP (08/07/83)
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"
dce@tekecs.UUCP (David Elliott) (08/15/83)
I think that Alan is right. Take the Bourne Shell for example. The damn thing is written in something that looks like Algol, except that the C code shows through. It's almost worthwhile to send it through the C preprocessor just to make it readable (I did this to look for some things I couldn't find the way it was). Macros should be used to clarify the code, not make it easier to program rather than learn C. David