Ada - DoD HOLWG, Col Wm Whitaker, 1993


There is a very large payoff to the DoD for being able to update hardware without having to rewrite the software. Further, there is a large payoff for being able to take modules of code generated on one project for use on another. Further, one would like to be able to use a common software base over a variety of machines and architectures within a single system. An identical functional capability may be required in a number of physical implementations of various sizes, speeds, and powers. These may require running the same code on a large scientific computer or a distributed system of microprocessors. The effort therefore emphasized two key factors of transportability: technical capability and control of implementations.

The technical capability for transportability and reuse requires that the source code be as machine independent as possible in items such as word length, the precision of variables, etc., and be able to specify representations and hardware dependencies in an encapsulated form. This was the requirement and Ada satisfied it. The effort was keyed to a hard definition of the language and validation of compilers to assure that a program written for one project or machine would be transportable in a realistic fashion. Control of the language was one of the most important aspects of this program and was planned for early on. Primarily, it meant maintenance of the final language specification including answering questions, making necessary decisions, distributing information as required, etc., and the certification of compilers. No compiler can be validated that does not respond appropriately to all legal programs, within our ability to test. Further, compilers must be checked to assure that they do not exceed the scope of the language. This idea of checking for features beyond the language was radical when first proposed, but it was vital to the overall purpose of the project. In some sense, it is not a matter of the language, but use of the language. Herein lies the difference between a "standard" and a "common" language. Standards are sometimes taken as a starting point from which deviations and "enhancements" proceed. If it is to be common, transportability and reuse depend on the language being the same everywhere. Here also is the origin of the controversial "no subsets/no supersets" rule.

I made it a principle that there were to be no subset and no supersets compilers for Ada. This was really not much of a problem in selling to the Services and the users. However, it was a continuous battle with the implementers, primarily academic. The argument was that they could make a cheap subset compiler to get started. This usually meant minor syntactic modifications to a Pascal compiler. Few of these subset advocates ever intended to go to a complete compiler. Some more serious proposals were made to define a standard subset of the language, in the manner of FORTRAN or COBOL. Those serious discussions failed to produce a proposal since everyone had a different idea of what features to suspend. Attacks on this policy continued long after I left the HOLWG and I periodically had to strengthen the resolve of my successors.

At the other end, there were those who insisted that there should be only one compiler, mandated by the government for all Ada users, or one per Service. There were those who demanded that all compilers use a common database for compiler syntax and semantics, or have a common intermediate language or internal interface. We had to confront this monolithic stance through a technical capability to assure that compilers from different sources would not generate dialects.

In October 1979, soon after the language was selected, a contract was let to SofTech to provide a suite of validation test programs. SofTech was a Phase I contender (Blue) and, while they were unsuccessful, their work showed an attention to detail that was ideal for this effort. John Goodenough led this program, for which he was required to distance himself from any SofTech Ada compiler contracts. The testers could not be developers.

The product of the contract was the Ada Compiler Validation Capability (ACVC) [Goodenough, 1980], a set of test programs, now numbering several thousand, which try the limits of the language. To validate, a compiler must not fail any applicable test. Standards facilities in the United States and abroad have been authorized to certify with this set of tests. It was recognized during the language development that testing, although never complete, was the only technically feasible method to assure compliance to the full and exact Ada standard. The test suite has grown through the years and since the purpose is to make sure a compiler is Ada, there was no leniency towards compilers that may have passed a previous version. When new tests are approved, compilers must revalidate, otherwise the validations expire. This is a significant burden on suppliers, but it is necessary to maintain the transportability and reuse goals, and is a consequence of the expectation that Ada must support high-integrity systems.

The idea of trademarking the name as a control on implementations was initiated while I was there, but not carried through until later. The use of the trademarked name, "Ada", was restricted to validated implementations. This gave very powerful psychological protection during the start-up when the concept of strict control was still vulnerable. In 1987, when the community had matured, AJPO relinquished the trademark protection.

While we set out to make a DoD common language, not necessarily a civil standard, we did work closely with the ISO PLIP Working Group (WG 1) so as to prepare for standardization as a method of control. I presented the HOLWG program to ISO SC 5 at the Turin meeting in the fall of 1978 to help prepare the way. The thought was to raise the control of the language to the highest level possible, out of the DoD, out of the United States, in order to make it harder for even a very large project to undermine the stability of the definition by propagating dialects, as had been the case with previous military languages.

In this connection, we needed to assure the world that this was truly an available commercial reality, and not something that the DoD was going to keep to itself. The openness during development contributed to this, but there were other pitfalls. Coincidentally, I was the US technical representative for computers in the export control arena where I sold the policy that there could be no control on languages that were subject to International Standardization, like FORTRAN, COBOL, or Ada; this cut off one possible disastrous scenario. Of course, this did not cover programs written in those languages.


Upon the completion of the development project in late 1980, Fisher and Carlson left, and the loose organization of the HOLWG was superseded by a DoD Ada Joint Program Office (AJPO), chartered 12 December 1980. Mark Grove was Chairman of the MSC-ECR and shepherded this through, along with Larry Druffel, who became the initial Director of the AJPO. This office managed the standardization processes with ANSI and ISO. One consequence of the transition was that this new organization was exclusively involved in the control and support of Ada, not in the overall DoD software problem. While initially proposed and budgeted to generate tools and applications libraries, the AJPO abandoned that role and concerned itself mainly with the control and with DoD policies.

The chief task was to continue to polish the language definition in connection with an ANSI canvass process leading to ANSI, and eventually ISO, standardization. A major challenge was to maintain close international involvement in the development and assure that national and international standards did not differ (a real possibility in the standards world of that time, but much less likely today). Through the usual Ada open process, the definition was refined to MIL-STD 1815A, and this was endorsed by ANSI in February 1983 [Ada, 1983], with updated Rationale [Ichbiah, 1987]. Ada was endorsed as ISO Standard 8652 in 1987.

A vital consideration in language control is that there must be some place to address questions and resolve ambiguities. A normal ANSI committee development has the possibility of using the committee itself as the ultimate judge. A process had to be devised for Ada. Ada is the responsibility of ANSI through an Ada Board advising AJPO, and of ISO through a Working Group, now designated TC 97/SC 22/WG 9. In the initial organization both of these groups were chaired by the then Director of the AJPO, Robert F. Mathis. At the time, this was a vital necessity for smooth coordination, forestalling possible divergences between the national and international standard. (When a later Director of the AJPO abdicated as WG 9 Convener, Mathis picked it up again and preserved this vital continuity.) There were elaborate organizational minutia and formal reporting and approval, but in essence, comments and questions on the language were resolved in summary papers, called Ada Commentaries, by the Ada Rapporteur Group (formally the Language Maintenance Committee), chaired by John Goodenough. All queries are recorded and considered. The resolution of issues are available from a number of sources and were a starting point for the language update.

Another possible path to control involved a formal definition of Ada. There are those in the computer science community who advocate a formal definition as the only way to specify a language. While this position is contested, formal definitions have been valuable in resolving difficult questions of interpretation. During the language development, the French (INRIA) began a formal definition based on denotational semantics [Donzeau-Gouge, 1979, 1980]. This effort was particularly noteworthy in that it used Ada as the metalanguage which made it much more readable than most formal definitions. In 1979, RADC redirected an effort that had been supporting to an operational definition of Preliminary Ada based on SEMANOL [Berning, 1980]. The NYU Ada/Ed interpreter was also advocated as an operational definition [Dewar, 1983]. Some Europeans were particularly interested in pushing a formal definition and proposed that such be the only basis for an ISO standard. The EEC supported research efforts in this area, beginning with the Danish work [Bjorner, 1980], and culminating in a large project completed in 1987 [Botta, 1987; Nielsen, 1987; Giovini, 1987]. While these efforts have illuminated a number of aspects of the language and have led to clarifications, the authoritative definition remains the natural language text of the Language Reference Manual.

Periodic review is required by ANSI and ISO for standards. Every five years a language standard must be revised or reaffirmed. Historically this has meant a revision every ten years. In 1988 the Ada Board reaffirmed 1815A to ANSI and began a revision process, working on an update for about 1993, prudently called Ada 9X. My only connection is that Christine Anderson, who is running the revision project, was at the Air Force Armament Lab at Eglin AFB at the time. While she did not join the Lab until after I left, I would like to think that my being there started a chain of events that led to her selection for 9X.


Since the purpose of the program was the improvement of DoD software, there were things beyond the language to be done, still within the scope of the HOLWG. Aspects of the development environment were studied with procedures similar to that for the language requirements. A document was prepared addressing those features of controlled support which would be required for the optimal utilization of the language. These were requirements in a different sense from the rigorous complete set of the STEELMAN, but the iteration methodology was also used here. An initial version, SANDMAN, drafted in January 1978, turned out to be entirely unsatisfactory and was never distributed. It did serve to show us that this problem might be more difficult than the language requirements, since languages were well known and environments were essentially non-existent.

In July 1978 a more appropriate document was issued, PEBBLEMAN [HOLWG, 1978c], replaced in January 1979 by PEBBLEMAN Revised [HOLWG, 1979a]. Peter Elzer did most of the work on this. Comment was solicited from the software development community, a somewhat different group than the language experts who addressed the language requirements. A meeting was held at the University of California (Irvine) in June 1978 [Standish, 1978] discussing all aspects of the requirements. In September 1978, a meeting at Eglin AFB, Florida, discussed primarily the technology of retargetable compilers [AFATL, 1978]. PEBBLEMAN covered such topics as the language configuration control board, whose responsibility is to maintain the definition and resolve any possible questions. A language control facility would provide validation and certification of compilers to assure that they conformed to the official definition within the limits of the current ability to test. The bulk of the document was concerned with defining those tools which could be provided in common to the use of language and outlining the methodology for producing and inter-relating those tools.

A further iteration, STONEMAN [HOLWG, 1980b], primarily the work of John Buxton from the University of Warwick, England, was concerned with the integration of a set of Ada tools. A meeting in San Diego in November 1979 reviewed the thrusts of software development technology and discussed a Draft of a STONEMAN. The STONEMAN was issued in February 1980. It formalized the layers or levels of the Ada Program Support Environment (APSE), with the supporting Kernel (KAPSE) and Minimal (MAPSE) levels.


It was never the intent that the HOLWG program would implement compilers. This was the prerogative of the individual Services and of industry. It was hoped that settling on one language would make it attractive for the industry to produce compilers as commercial products, without government funding or control (as it has worked out). However, it was important that the Services show support for the standard by putting their money into some products. If no one thought the Services were interested (and money spells interest), then why should industry risk its own money? It was not actually necessary that the Service programs be successful, just that they exist. Indeed, there was a certain inhibitory factor; a company may not want to invest in a compiler for a particular machine if the government was doing the same and it might be available for free later. So we walked a fine line. I do not know how we could have proceeded differently. Tools and environments were also the province of the Services and industry.

There were several early implementations that should be noted. In connection with the language design there was an interpreter produced by Honeywell. This ran on the MULTICS system and fielded at MIT and Rome Air Development Center (RADC) for use in the Test and Evaluation phase. It let a large number of users get hands-on experience over the ARPANET very early, but it was incomplete and very slow. Because of these limitations, it was important to provide a more satisfactory support for those evaluating the language. Another interpreter was produced in 1980 by Intermetrics for the DEC-10. This was made available via the ECLB machine on the ARPANET. While certainly limited, it was much more useful than the previous system.

A complete interpreter, called Ada/Ed, was done by New York University. Although nominally for "educational use", this evolved to a complete, validatable system, which served to explore implementability during the polishing phase. It was considered by its developers to be an operational definition of the language. It was initially implemented in the set language SETL on a CDC Cybermachine.

The US Army (CORADCOM) contracted for the first large scale Service effort, the Ada Language System (ALS). This consisted of a complete environment along STONEMAN lines, including a production quality compiler. This development was contracted to SofTech in Waltham, MA. The implementation was done in a "Pascal-like" subset of Ada and was hosted and targeted for a DEC VAX. This effort was managed as a major system procurement, not a research effort. There was a competitive procurement, elaborate design documentation for every facility of the system, and a very large commitment of funds. The outcome was disappointing and the project was eventually shelved. Strangely enough, some time later the Navy chose this to be the basis of their major procurement, called ALS/N, although with another contractor. Cross compilers hosted on the VAX from this effort, called ADA/L (targeted for the AN/UYK-43) and ADA/M (AN/UYK-14 & 44), have been validated, but have not generated much general interest.

The Air Force (RADC/IS) initiated a similar procurement in 1980, called the Ada Integrated Environment (AIE). This was also a two-step competitive procurement. A design run-off was held among the first phase contractors: Computer Sciences Corp., Intermetrics, and Texas Instruments. The winner selected for the full-scale development was Intermetrics in Boston. The AIE was coded in a large subset of Ada and hosted/targeted to IBM 370 series machines. The contract included also both a compiler and STONEMAN environment. This project also fell on difficulties and the environment portion was deferred in favor of completing the compiler. Eventually the contractor completed the compiler after the expiration of the contract. Both the ALS and the AIE were embarrassing contractual failures for the sponsoring Service; however, they were necessary for the overall effort.

While I was at AFATL at Eglin, I proselytized for Ada and converted some people. Captain Jim Bladen did an early in-house compiler (hosted on a CDC Cyber, targeted to a Zilog Z8000 microprocessor) that is notable in that it led to what I believe was the first "operational" military use of Ada [Whitaker, 1983]. In early 1981, Jim Jones of AFATL programmed a briefcase Z8000 computer to checkout missile computers upon delivery. AFATL also contracted with Florida State University for a compiler. This was validated but found no users.

The British Government sponsored an effort at the University of York, subsequently York Software Engineering, that eventually validated. The German MoD contracted with University of Karlsruhe and GPP for an Ada compiler for the Siemens 7000 series machines.

The expectation of good, validated commercial compilers was fulfilled. Validation of 1815A implementations started shortly after ANSI approval. The first 1815A validation certificate was issued for the Ada/Ed interpreter on 11 April 1983, followed quickly by compilers from ROLM and Western Digital STC. There was an initial slow growth of implementations as companies mastered the language. By 1987 there were more than 100 validated compilers, and by 1992 this number had grown to about 400.

There were two sidelights of the compiler thrust, DIANA and CAIS.

By 1980 there were a number of large Ada compiler efforts underway. They were all facing the same problems with the same level of technology. In sharing experiences, it was noted that the projects used different, but technically similar, high level intermediate languages. The two main representations were TCOL-Ada from Carnegie-Mellon University (CMU) [Newcomer, 1979] and AIDA from the University of Karlsruhe [Dausmann, 1980]. By August 1980, there was a general feeling in the Ada community that these were close enough that there should be some effort at reaching common ground. Unfortunately, there never seemed to be time for the busy developers to get together, so nothing was happening. It appeared to me that a great opportunity was being missed, so I approached the government sponsors of the compiler developments at the December 1980 SIGPLAN Ada conference in Boston and convinced them to use the power of the purse to encourage the necessary coordination.

In January 1981, I hosted a two week parley in my office at Eglin AFB with representatives from Karlsruhe (G. Goos, G. Winterstein, M. Dausmann), CMU (W. Wulf, J. Nestor, D. Lamb), Softech (R. Simpson, L. Weissmann), and Intermetrics (B. Brosgol, M. Tighe). I supplied coffee, cookies, and fruit, and would not let them out until the matter was resolved. Agreement came much quicker than anyone had imagined, and DIANA (Descriptive Intermediate Attributed Notation for Ada) was born [DIANA, 1981]. DIANA, is a high-level tree-structured intermediate language for Ada and provides communication internal to compilers and other tools. It used the abstract syntax tree of the formal specification and had many attributes based on AIDA. From TCOL-Ada it inherited the symbol table attributes and some separate computation features. The meta-notation is the Interface Definition Language (IDL) of CMU. There were some differences between the formal definition and Diana. These were all resolved in early February at a meeting in Murnau, Germany.

DIANA was never supposed to be a standard to be enforced on all implementers. The purpose was simply to avoid duplication among those who were doing approximately the same thing anyway. There was some continued maintenance of DIANA [DIANA, 1983, 1986]. It is being used by a number of developers, although with some variations. Other implementers have opted for different representations.

Another Ada-related standardization initiative was the Common Ada Interface Set (CAIS). This started somewhat like DIANA. Since the ALS and the AIE were comparable Ada environments, it seemed a good idea to have a common interface definition to promote tools interoperability. In September 1982 a definition was begun by a DoD Kernel Ada Programming Support Environment (KAPSE) Interface Team (KIT) to foster compatibility between the ALS and AIE developers. Shortly the goals were expanded and volunteers were solicited (through a Commerce Business Daily announcement) to form a KAPSE Interface Team, Industry and Academia (KITIA). The CAIS Version 1.0 [CAIS, 1983; Oberndorf, 1983] was released for comment in September 1983. Eventually it developed into MIL-STD 1838 [CAIS, 1986]. This interface has not been generally adopted, having lost the impetus that might have been sustained if the ALS and AIE had been successful, but it is the US contribution to a cooperative effort with Europe.


An informal group known as the Ada Implementor's started meeting in May 1979 led by Gerald Fisher of New York University (NYU), which was developing Ada/Ed. This was the idea of Serafino Amoroso, a HOLWG representative of the Army, which was funding NYU. By August 1980 the group was issuing an Ada Implementor's Newsletter, edited by Mary Van Deusen of Prime Computer, Inc., which provided the financial backing. Wishing to establish a more formal organization, the group voted at the March 1981 meeting to seek recognition, and in a vote chose to affiliate with the ACM (vs. the IEEE). The name of the Newsletter was changed to Ada Letters [ACM, 1981]. On May 6, 1981, this group was chartered as AdaTEC, a technical committee under ACM SIGPLAN; Gerald Fisher was appointed Chairman. In 1984 the group was rechartered as SIGAda, the ACM Special Interest Group on Ada, and elected its first Chairman, Anthony Gargaro. This organization has provided the civil forum for Ada technical discussion and publication. It holds and sponsors frequent meetings that are the voice of the Ada community. By 1980 an Ada UK organization was established, and more than a dozen other national organizations are now active. Ada Europe provides a European forum much like SIGAda. There is an active, organized, worldwide community outside the DoD devoted to the use of Ada, as the HOLWG had hoped, and which did not exist for previous military embedded languages.