PASCAL like C with no sweat
kri...@cg-d.uucp
of information on mapping PASCAL to C and vice versa. I migrated to
C from PASCAL, and to help the transition, I developed these macros. But
I have continued to use them because they have made my *C* programs
eminently more readable. Making the transition back from hard core C
may be difficult, but for those of ye who are new to C this may help...
/* Cut here -------------------------- ereh tuC */
#define begin {
#define end }
#define true 1
#define false 0
#define TRUE true
#define FALSE false
/* Control Structures */
#define If if(
#define Then )
#define Else else
#define While while(
#define Do )
#define For for(
/* Misc Stuff */
#define boolean char
#define and &&
#define or ||
#define not !
#define record {
/* Cut here ------------------------- ereh tuC */
/* Sample uses ... */
While true Do ...
For i=0; i < Junk; i++ Do
If (x < 10) and not found
Then begin
fdgkgj;
sdfkslf;
end
Else dkfhgkjfdhg;
See .. No extraneous '(' and ')'. Makes the code look really clean.
------
In real life: B. C. Krishna @ Compugraphic Corp. MA.
UUCP : ...decvax!cg-d!krishna
g...@gorodish.uucp
>these macros. But I have continued to use them because they have made
>my *C* programs eminently more readable.
Oh please, not again... the question of whether macros that make C
look like something else make the programs more readable or less is
one that has several answers, depending on the person who is asked
the question. Can we please not reopen this debate?
gw...@brl-smoke.uucp
>#define begin {
>[etc.]
Please don't do this. We already went through years of having to
cope with Bourne's Algol-like shell sources; there was nearly
universal approval among experienced UNIX C programmers when the
shell sources were converted back into C.
The main problem is that "begin...end" is not more readable than
"{...}", except perhaps to people who have gotten very accustomed
to the former but not the latter. Since C programmers have to
learn the normal language syntax anyway, all you're doing with
the wordy definitions is forcing anyone who has to deal with your
code to learn an additional set of conventions. That is more work,
not less.
Note also that "end" is an important extern datum name on some
systems; by introducing more keywords, you've removed them from
those available for use as program symbol names.
Another problem is that the equivalence between your C macros and
the corresponding Pascal macros is not exact. For example, && has
additional properties over those of "and".
The Boolean data type definitions would be okay if introduced as a
data abstraction and used strictly for Boolean data. However, the
natural Boolean type in C is (int), not (char), since that is the
type of Boolean expressions such as "p == q". You also don't need
two names (true and TRUE) for the same thing.
Sorry to pick on you, but I may have to maintain some of your code
someday.