amull@Morgan.COM (Andrew P. Mullhaupt) (02/02/90)
In article <587@mwtech.UUCP>, martin@mwtech.UUCP (Martin Weitzel) writes: > In article <1922@gmdzi.UUCP> wittig@gmdzi.UUCP (Georg Wittig) writes: > >jwl@ernie.Berkeley.EDU (James Wilbur Lewis) writes: > > > >>In article <Jan.24.10.40.15.1990.15842@police.rutgers.edu> andrewsr@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