#defining a 'better' C (was Re: #define OR ||)
Andrew P. Mullhaupt
amull at Morgan.COM
Fri Feb 2 03:06:33 AEST 1990
In article <587 at mwtech.UUCP>, martin at mwtech.UUCP (Martin Weitzel) writes:
> In article <1922 at gmdzi.UUCP> wittig at gmdzi.UUCP (Georg Wittig) writes:
> >jwl at ernie.Berkeley.EDU (James Wilbur Lewis) writes:
> >
> >>In article <Jan.24.10.40.15.1990.15842 at police.rutgers.edu> andrewsr at police.rutgers.edu (Richard L Andrews) writes:
> [pro's and con's about "#define OR ||" deleted]
>
> All the time since I teach C, after introducing the preprocessor
> this ideas come up and many newcomers try to change C into the
> language, they happen to love most (at this time). The situation
> here in germany is worse in so far, as some eager students rapidly
> produce #define-s for german keywords, ie. "#define wenn if",
> "#define solange while", ...
>
> So feel free to #define your 'better' C, but don't expect it to
> become quickly in broad use :-)....
> ... I bet, sooner or later you'll retract to
> the original (and IMHO beautiful) "plain" C.
Three quick points:
1. There are benefits to having natural language independence
in a programming language. APL, (which has a trivially
small set of 'words' in it - they're all in error messages
and 'commands') is widely used in Asia. You can select the
language you want error messages and commands to be in by
setting the value of a system variable, (quad NL). Thus it
is trivial for programmers who have no common natural language
to work on the same APL source. (Another way to put this is
that APL is equally unreadable from all natural language
points of view.)
2. Algol 68 explicitly allowed for changing keywords, etc. to
support just this sort of thing. (Yet another 'if only we
had Algol' comment).
3. As I pointed out in my previous posting, it seems to me that
the only really workable way to alleviate the 'readability'
of usual C is to write a code generator, which produces
C output. If you want a fairly low level of 'cosmetic'
improvement to C, this isn't too hard to do properly. It
also supports industrial strength modifications to the
language, (like C++ and Modula-3).
Finally:
This theme is so common, and so many C programmers have pointed
out the 'newcomers to C' or 'neophytes' or 'C illiterate brain dead
Pascal demagogue hacks' always want to do this sort of thing. It
seems that enough people have this reaction to C to justify some
real tools to make this sort of thing less dangerous and painful to
all. One such tool would be a device which could create 'Indian Hills'
style source from personalized, dialect C. Essentially, what I have
in mind is like cpp, except that you would have two levels of
preprocessor directives - those which allow the author to write his
code according to his own conscience, and those which grab gobs of
header files to declare all sorts of stuff (the more traditional use
of #include and #define, etc.). The thing reads the dialect source, and
expands all the directives which relate to the dialect. It would likely
help for the originator of the dialect to provide some templates in
a file to assist generation. Then the first step of code maintenance
for the 'traditionalist' programmer is to skip the slang, and look at
a copy of the standardized source.
I don't think this breaks any source manipulation tools in UNIX
(that aren't broken already - N.B. indent, etc.) because all you need
to do is have make create the .c files by running this pre-preprocessor.
The biggest downside in this whole thing is that you really don't
want two people with different dialects to be maintaining the same
source file. The fact that ultimately, the standard style C source
may be needed as a substrate for interprogrammer communication is not
any worse a situation than exists now, and in fact might have the
advantage of uniformizing the C source representations to a greater
degree than exists today.
Later,
Andrew Mullhaupt
More information about the Comp.lang.c
mailing list