Re: Last Ada Diatribe for 90

[stt@inmet.inmet.com]

In response to Ted Holden's "Last Diatribe":

I am reluctant to respond since I would hate to cause
Ted to violate his promise, but I felt a little bit of
fairness was in order.

Ada9X is intentionally a very open process,
and encourages the reporting of all gripes, both serious
and frivolous, about Ada83.  This will certainly
result in a lot of dirty laundry if there was a desire
to claim that Ada83 was spotless.  However, the point
of Ada9X is precisely to address the problems, not to hide them.

I am sure if you were to look inside the ANSI C standardization
effort, you would have found large numbers of perceived problems
with K&R C, and a standardization committee which did its
level best to address as many as them as was practical.
Similarly, the ANSI C++ standardization effort is just beginning,
and it is destined to be a very interesting, heated, and
hopefully productive process, with lots of dirty laundry, etc.

Ada83 took a different approach from C and C++.  It attempted
to both break new ground from a language design and integration
point of view, and rigorously standardize prior to a period
of industry use.  
Languages which didn't standardize during their first
years of use continuously evolved to address the gripes, meaning
that presumably fewer gripes accumulated.  Certainly C++ over the
past few years has been a moving target.

There were both good and bad reasons (in retrospect)
for the early standardization approach of Ada83.  
Nevertheless, we are now at the stage
of rounding up all of the big and little gripes which have
accumulated during the past 8 years or so, and there are admittedly
a lot of them, partly because the language has been rigidly
standardized during this period of initial use.  

Of course, we didn't specifically ask for
the list of good things about Ada, things which make it
better for large-system development, for embedded-system development,
for C3I development, for man-critical systems, etc., 
when compared to other widely available
languages.  We actually did receive a few unsolicited requests like "please
don't change this, I like it the way it is".  But by and large, most
requests came from people who seriously want to continue using
Ada rather than some other language, but have run into some problem
or other which they would ideally like to see fixed.

Just for reference, here are a few of the things which
Ada83 tried to integrate into a single language.  If you were
to compare C, Pascal, etc. of 1980 with where languages are now,
you will find that many of the ideas promoted by Ada83
have since been incorporated into C, C++, Modula-2, Concurrent C, etc, or
are now being considered.  Some of this was parallel evolution.
Other changes in these languages were based directly on 
lessons from Ada's successes and problems.

So here's the list:

1) Strong type checking across separate compilation, with
a persistent program library structure.

2) User-defined data abstractions (private types)

3) Generic package/subprogram templates

4) Exception handling

5) Multi-tasking within the language

6) Synchronization primitives within the language

7) Inlined subprograms

8) Explicit separation between logical data structure
definition and physical data representation definition

9) "Safe" pointers, with multiple heaps.

10) Complete array bounds checking, null pointer checking, scalar range
checking, access-before-initialization checking, function-return-without-
a-value checking, etc., carefully specified as part of the language definition.

The net effect of all of these language features is that
Ada is an excellent language for the building of large systems,
providing excellent interface definition and control, and
catching many errors at compile-time, and most remaining errors
at run-time very close to the point of the defect.

However, the size and sophistication of the language posed
more problems for compiler-writers than was originally anticipated.
In retrospect, the "let the compiler do it" and/or
"just throw fancier instruction sets / more horsepower at the problem" 
attitudes had perhaps been taken too far 
(remember CISC was still king in the early 80's).

We now know RISC is king, and small and fast is better
than big and fancy.  However, there is no denying by anyone
who has used Ada, that its features do make interface control
and debugging much much easier.  Ada programmers don't want to return to
the arbitrary address arithmetic of C, nor its single-level
global name space.  Watching the evolution of C++
is highly instructive, as it tries to incorporate exceptions,
generics, concurrency, etc.  It will be a real struggle
to fit C++ 3.0 on an old-style PC.

The challenge for the designers of Ada9X is to retain the existing
features of Ada83, while achieving better run-time and
compile-time efficiency.  We believe this is possible
by "simplifying through extension" and providing a small but complete
set of additional safe low-level primitives.

Simplifying through extension means removing special cases and limitations
in the language, and unifying the capabilities so that all reasonable
operations are applicable to all reasonable objects.  This has the
potential for both simplifying the compiler, and making the language
more flexible for the programmer.

Providing a small, complete set of safe low-level primitives
may require no more than a carefully designed set of standard
packages, with minimal additional linguistic support.
"Safe" means that the new primitives should avoid introducing
situations where random memory can be clobbered, or other "erroneous"
unpredictable behaviour can occur.
Ada83 is excellent at "damage control", where a bug in a program
is detected at or very near its occurrence, before propagating
failures to other parts of the program.  Any new set of
low-level primitives should preserve this important attribute.

As a final point, the Ada9X process is attempting to address
the compiler availability issue from the very beginning.
There will be about three funded user/implementor teams,
which will be paid to evaluate and implement the language
changes as they are proposed.  In addition, we anticipate
structuring the changes so that those which address the
most critical problems will be implemented first, as an
incremental change to existing compilers, rather than as a major
rewrite.  This should mean that these most critical
fixes will be available, at least for trial use, within
the next few years.  The more forward-looking changes may
not be available until later, but presumably these are
less critical today.

S. Tucker Taft    stt@inmet.inmet.com
Ada9X Mapping/Revision Team
Intermetrics, Inc.
Cambridge, MA  02138