Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.UUCP
Newsgroups: comp.lang.c
Subject: Re: PASCAL like C with no sweat
Message-ID: <5630@brl-smoke.ARPA>
Date: Sun, 15-Feb-87 10:53:00 EST
Article-I.D.: brl-smok.5630
Posted: Sun Feb 15 10:53:00 1987
Date-Received: Wed, 18-Feb-87 20:09:45 EST
References: <257@cg-d.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 33

In article <257@cg-d.UUCP> krishna@cg-d.UUCP (B.C. Krishna X7219) writes:
>#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.