From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: Wed, 14 Jul 93 09:57:59 -0700 From: mshapiro@manta.nosc.mil (Michael D Shapiro) Subject: How does your language grow? (Follow-up on comments on ADM Tuttle comm ents) Message-ID: <9307141657.AA27874@manta.nosc.mil> List-Id: Colin James 0621 wrote (in part): ... > The extent of the misinformation about C++, for example, has now > infiltrated AT&T's C courses where it is now taught that C++ IS a > compiler (it's a precompiler that churns out C code with no regard > to the C compiler backend) and that C++ makes faster running code > than C (it does not because anything done in C++ can be programmed > to run faster in C). ... C++ started as a preprocessor for C code. It allowed new ideas to evolve and be tested, as C++ grew, without requiring major reconstruction of parts of the language processor for each change. Certain inefficiencies exist in this type of language processing, although (as I've taught in compiler construction courses) it's a convenient way to build new compilers. Someone wanting to improve the efficiency of the compiling process (usually for commercial advantage) will combine the two language processors into one, a true C++ compiler. I've been out of the compiler business for a few years, but I believe this has been done. This approach has been very common in compilers and language processors over the years. We try new ideas and features with preprocessors. When the ideas gel and are accepted into the language, people start including them in compilers. FORTRAN started out as a fixed format language (with boundaries based on the character and word size of the IBM 704/709 and successors). When on-line Teletype preparation of programs came along, preprocessors translated free format input to the standard layout. I recall controversy over one such preprocessor that I described in a paper at the 1970 ACM FORTRAN Forum. (The work was part of Purdue's PTSS effort, extending the PUFFT Fortran system with a terminal front end.) One question seemed to be whether a language that allowed free-format input could (or should) be called FORTRAN. Well, a form similar to what I described is now in the standard for what is now called Fortran. A few years later, Kernighan and Plauger's RATFOR introduced C-like statement concepts as an extension for FORTRAN. Features from that and similar language efforts were accepted as the way the language should evolve and are now in the Fortran standard. On the other hand, some features of early FORTRANs (for example, the FREQUENCY and READ INPUT TAPE statements) were recognized as obsolete and have disappeared. Perhaps one of Ada's acceptance problems is that experimentation allowing expansion and contraction of the language have been discouraged. This mode has given gradual growth of most other programming languages, supporting new programming paradigms as they arise. Periodic standardization describes a consensus of the then-current state of the language. The new features allow the languages to increase their level of helping programmers in writing programs. Ada has had some preprocessor work, but for the most part changes have had to wait for the next giant step, Ada 9X. While large-scale program managers may get warm feelings from this approach, many language experimenters (who might significantly improve the definition) become uncomfortable waiting for the next orders. They choose to ignore Ada. Michael Shapiro (These views are my opinion. My employer may or may not agree.)