How does your language grow? (Follow-up on comments on ADM Tuttle comm

How does your language grow? (Follow-up on comments on ADM Tuttle comm

[Michael D Shapiro]

Colin James 0621 <cjames@dsc.blm.gov> 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.)