Ada - DoD HOLWG, Col Wm Whitaker, 1993

HOLWG

The intent was to have a common real-time language to replace the existing mix, while maintaining the standards of FORTRAN and COBOL, the success of which had provided impetus to this consolidation program. Further, to assure non-proliferation during this effort, all other implementations of new high order programming languages for R&D programs were halted. The January 1975 DDR&E memo (Figure 1) to the Military Departments directed "A working group should be formed from representatives of your Departments and chaired by ODDR&E" establishing the HOLWG, and making it the agent for this effort. This initial authorization was the first major milestone of the project; others are listed in Figure 14.
At this point it is necessary to explain something about the workings of OSD. Contrary to what one might expect, OSD does not rule the DoD and the Services with an iron rod. The main control is money, and the DoD has very little money of its own - most of the money is appropriated to the Services. But the Service funding passes through DoD on the way, and the distribution process could get very slow and sticky, so the Services do listen. Nevertheless, OSD actions can usually be characterized as coordination. If OSD memos, like that setting up the HOLWG, sometimes seem to be expressed mildly, one should not misjudge their import. There are fairly few directing memos. They, like Directives and Instructions, are extensively coordinated before they are issued, not only within OSD but with the Service recipients. Characteristically, the action is agreed to by all parties, not necessarily without some arm twisting, before a memo is signed. Everyone knows the intent and what is expected, even when the memo is worded gently and with delicate political sensitivity. So a memo may mean more than it says.
The membership of the HOLWG consisted of a chairman, myself, appointed by and representing DDR&E, plus representatives of each Military Department appointed by and reporting to the Departmental Assistant Secretaries (Research & Development), plus other components and agencies to be called upon to present their comments and specific expertise. (Specific membership of the HOLWG is discussed later.) Throughout the program, authority came from DDR&E and the memos were the form of communicating this authority. These memos may appear to be mild, not what one might think of as a military order, but in the DoD this is the way most things get done. Each DDR&E memo was a major milestone in the effort.

Figure 1

[All memos and figures have been retyped]

DIRECTOR OF DEFENSE RESEARCH AND ENGINEERING

WASHINGTON, D. C. 20301

                                                            28 Jan 1975

MEMORANDUM FOR ASSISTANT SECRETARIES OF THE MILITARY DEPARTMENTS (R&D)
SUBJECT: DoD Higher Order Programming Language

In studying the computer software problems of the DoD, it has become
clear that standardization in higher order programming languages is
necessary.  The advantages in training, instrumentation, module
reutilization, program transportability, etc. are obvious.  In business
and scientific applications, COBOL and FORTRAN have evolved as
standards, but in the areas of weapon systems, command and control, test
equipment, etc., the DoD has supported a large number of limited use
developments, many for a single project.

That each of the Military Departments has independently proposed a
standard military language to supplement COBOL and FORTRAN testifies to
the need.  We concur that such standard language efforts should do much
to reduce the high cost of software to the DoD and further suggest that
the benefits would be multiplied if a single common military language
were the outcome.  We call upon the Military Departments to immediately
formulate a program to assure maximum DoD software commonality.  A
working group should be formed from representatives of your Departments
and chaired by ODDR&E.  This group will investigate the requirements and
specifications for such commonality, compare with existing DoD efforts,
and recommend adoption or implementation of the necessary common
language or languages.

My office has informally discussed this in some detail with various
Service Offices, primarily USACSC, NAVAIR-360 and AFSC/XRF.  We have
been working closely with OASD(Comp) and OASD(I&L) who will also
participate in the study.  Until the matter is resolved, we do not
intend to support any further implementation of new higher order
programming languages in R&D programs.  As this may impact proposed
program schedules, we regard the completion of this task as a matter of
urgency and request you name working group representatives within one
week of the date of this letter.  You may have your representatives
contact Lieutenant Colonel William A. Whitaker, OX7-4197.

                                      Malcolm R. Currie

The organization and procedures of the HOLWG were up to the chairman - anything I could make work. The only reporting was to DDR&E and I made the reports. This sounds dictatorial, and to a large degree it was, but it only worked as long as I held it together. In fact, it was a consensus operation. Every formal vote that the HOLWG ever took was unanimous! That is not to say that there were not many lively discussions and opposing views, but I waited until everybody agreed on a course of action before posing a formal vote. The question was usually not "which of these is your favorite?", but "which should be the HOLWG choice?" Under those conditions, the HOLWG functioned smoothly.
The HOLWG was not a committee of language designers. It was a group representing the users. It eventually contracted for language designers, but design was not its only function. The exact working membership of the HOLWG was never a fixed list. I was the only name mentioned in the DDR&E memo, as Chairman. After that the HOLWG was constituted from members nominated by the Services. There is a list in the Charter of November 1976, but it is pro forma and does not necessarily represent the workings of the group.
Each of the Services has its own personality and that was reflected in the personnel assigned to the HOLWG. The Army is very formal and works on orders, often from the Adjutant General (TAG). Major Brehault from Army Computer Systems Command (USACSC) was the first representative, replaced on his reassignment by Major Ben Blood. Dr. Serafino Amoroso from Ft. Monmouth was brought in as a technical representative of the Electronics Command (USAECOM then CORADCOM).
For the Air Force, whoever is in the office responsible that is the representative. Lt. Col. John H. Manley from the Air Force Systems Command (AFSC) was their first representative, shortly followed by Major Thomas H. Jarrell. Samuel A. Di Nitto of Rome Air Development Center (RADC/ISIS) gave technical support. Col Robert Ziernicki and Lt Col John Marciniak provided headquarters (AFSC/XR) support. Eventually Major Al Kopp represented the Air Force to Ada, and Ada to the Air Force.
The Navy is much more complex, because it is organized along the lines of major platform types (air, surface, and land). Bernard Zempolich, then with the Naval Air Systems Command (NAVAIR), was an original member, as was Robert Kahane. Lt Col Joseph G. Schamber represented the Marine Corps during the entire life of the HOLWG. CDR Jack D. Cooper was subsequently designated representative by the Naval Material Command (NAVMAT). LCDR David C. Rummler from ONR-London facilitated our early European contacts and meetings. Warren Loper of Naval Ocean Systems Center (NOSC) was brought in as technical expert, and no one worked harder or contributed more than he.
The Agencies were represented by William Carlson (DARPA), Paul Cohen (Defense Communication Engineering Center of the Defense Communications Agency - DCA), and Steve Squires followed by Terry Ireland (National Security Agency - NSA).
Dave Fisher (IDA) was the technical secretariat of the HOLWG and ran all aspects of the technical operation.
This project was conceived of as an effort in international cooperation and a number of Europeans were involved, in the meetings, working full-time in Washington, or coordinating and supporting from Europe:
For the United Kingdom Ministry of Defence (UK MOD), the Royal Signals and Radar Establishment (RSRE - Malvern) contributed the efforts of Nick Neve in the United Kingdom and Philip Wetherall who spent a year in the United States working within the DoD structure on the Ada effort.
For the Federal Republic of Germany (FRG), Dr. Horst Clausen (Industrieanlagen-Betriebsgesellschaft mbH - IABG) was in close contact with the project and attended HOLWG meetings. Dr. Eberhard Wegner (Gesellschaft fur Mathematic und Datenverarbeitung) provided governmental coordination. Dipl. Phys. Peter Elzer (Physics Instiutut, Erlangen) spent a year in the United States working on the program. His representation was particularly gracious since he was responsible for PEARL, the language that the Germans had proposed for an International Standard with which the HOLWG product would be in direct competition.
For France, Nicholos Malagardis (Bureau d'Orientation de la Normalization en Informatique) and Jean Robert (CAP-Sogeti Logiciel) were especially helpful, and P. A. Parayre representing the Ministre de Marine made many trips to attend HOLWG meetings.
Each of these countries was fully consulted and a voting member of the HOLWG. (At this time there was an initiative called the "Two Way Street", which was to promote Defense acquisition cooperation between the United States and its NATO allies. The DDR&E once told me that he thought that the HOLWG program was the only example that was working.)
Other Federal organizations were kept informed of the HOLWG progress but were not involved programmatically to any significant degree. By contrast, members of the standards community for COBOL, FORTRAN and PL/I were major contributors to the HOL investigations. The Navy COBOL Validation Facility had a major input for validation concepts.
Requirements
The HOLWG was established to (a) formulate the requirements for common DoD high order languages, (b) compare those requirements with existing languages, and (c) recommend adoption or implementation of the necessary common languages. This was the original charge in the DDR&E HOLWG memo, that is, this was a direction taken before the formal organization of the HOLWG. There was work, and a number of memos to the Services, before the January 1975 founding of the HOLWG.
The first charge to the High Order Language Working Group was to establish requirements. In terms of reference, the working group was to consider general purpose computer programming languages. This was a limited goal and did not include either generalized requirements languages or very specific applications packages, which are formulated like languages but have only limited access to the capabilities of the computer. Such applications-specific languages include simulation programs, such as SIMSCRIPT or GPSS, and ATLAS, an automatic test equipment language which is for communications between the test engineer and the technician and is the DoD standard for maintenance test.
There were "requirements for requirements", part of the background of any engineering project, well known by those involved, but often unappreciated by those on the outside. In discussions, we often forget to state some of these because they seem so obvious, but I will mention a few that did not seem to be understood in the academic community.
The new language project was a DoD engineering development and had to live in the DoD environment. This project did not set out to break new ground nor invent new computer science, nor was its purpose to showcase particular ideas of language design, but it did have to push some ideas into concrete form. It had to produce a powerful and complete language, or it could not satisfy the requirement of being able to implement whole systems with machine independence (for portability), avoiding the extensive assembly language inserts that plagued then-current DoD HOL applications.
The character set discussion is a prime example of misunderstanding of the basic environment. For the DoD there was never any question. From 1955 to 1975 we had progressed from IBM 026 to 029 key punches, and there still were old ones in the field, and many machines used 6 bit characters! To be able to write programs in that environment, so there was a requirement for the language to work with a limited character set. The comments from the major Computer Science Departments universally condemned this "step back". They said we must have 256 characters. They all had local systems with many interesting properties, each incompatible with everything else in the world, which they assumed were available to everyone. From DARPA I had a chance to inspect a large number of such facilities and never could get much recognition that they did not represent the real world. (Note that the world never did go to APL, or even PL/I, keyboards.) (The ISO LATIN-1 proposal for Ada 9X has no relation to anything academically proposed for an 8-bit set in 1976. Even now, any extension beyond LATIN-1 is ambitious.) They would say that ANYBODY can do it, but for a common language the requirement is that EVERYBODY can do it. The purpose of HOLWG was a common DoD language. (This leads to a standard language, but the converse is not necessarily true. One may need a standard even for very limited use.) In the absence of such practical considerations, the reliability goal would have demanded that there be no distinction between upper and lower case in identifiers. Jean Robert of CAP, the largest software house in Europe, and LTPL-E, vetted the final 55-character set requirement for European acceptance.
Another requirement in this area was for fixed point arithmetic. While large scientific machines had provided floating point hardware for decades, such facilities had not reached military weapons computers. Many had difficulty understanding a fixed point requirement which was in the language, for purely practical, not mathematical, reasons, prompting a special study [Fisher, 1978a] in this area. (An extraordinary situation was generated when Headquarters Air Force, contrary to recommendations from the field, adopted, in 1976, a standard language for avionics software that provided only floating point arithmetic. At that time the Air Force had no avionics computer with floating point hardware! [Whitaker, 1990])
There were other common language meta-requirements. For example, the language must be an applications user language. This went against certain academic concepts of a mathematically minimalistic formulation, like ALGOL 68. The language must also be "complete" in the sense of the user being able to write all usual programs without having to resort to assembly language or local extensions. It had to have real-time capability and it had to be set up to produce programs for the bare machine in a missile, without support of an operating system. It also was required to support large Command and Control systems, so it had to have a file input/output system, however messy that might be.
The applications for this language were the large, long-lived, and lethal systems of the DoD. The users were the military and contractor personnel developing and maintaining these systems. These were professionals in a professional environment, not students or hobbyists. They would have various levels of talent and experience, but would be expected to have discipline, management, and adequate hardware and software support. The environment was one of large teams. The systems were compiled, so there was no requirement for the language to be interpretable on-the-fly, although there was nothing against that. Resources should be sufficient that one could support a compiler which could do extensive checking. The cost of compilers and the computer resources they demanded would be offset by the benefits of reliable systems and reduced maintenance.
Since the developed systems were to be long-lived, maintenance and modification of the software would cost several times as much as initial development. Readability was much more important than writability, a requirement contrary to those advocating the "economy of expression" that leads to incomprehensible C and APL code. Maintainability also argued for rigid interfaces and powerful compiler checking.
There were also certain "non-negotiable" demands of the users. The Navy insisted on a "goto" being written in as a basic requirement. There were, and may be still are, those in the Navy not enthusiastic about the project, so we paid that price for coordination.
The technical goals of such a high order language that were agreed upon at that time were the following:

The language should facilitate the reduction of software costs. The costs must be reckoned on the total burden of the life cycle including maintenance, not just the cost of production or program writing.

Transportability allows the reusing of major portions of software and tools from previous projects, and the flexibility for a system to change hardware while keeping the same software.

The maintenance of very long lived software in an ever-changing threat situation requires responsiveness and timely flexibility.

Reliability is an extremely severe requirement in many Defense systems and is often reflected in the high cost of extensive testing and verification procedures.

The readability of programs produced for such long term systems use is clearly more important than coding speed, or writability.

The general acceptability of high order languages is often determined by the efficiency and quality of the compiled code. While rapidly falling costs of hardware may make this difficult to substantiate in the abstract, each project manager will compare the efficiency of the object code produced against an absolute standard of the best possible machine language programming. Very little degradation is acceptable.

While these goals and "ilities" can be accepted, they do not lend themselves to a quantifiable or rational assessment of programming languages. We needed to establish criteria which were sufficiently explicit, determining the capability but not necessarily the form of the language. Rigorous definition of the exact level of requirement proved difficult. The method chosen for the preliminary requirements was to define this level by illustration. The HOLWG considered the problem from their experience of other developments and found that it was going to be difficult to do justice to the task, in fact, it was hard to even get started. Finally a group from the HOLWG just sat down and proposed a set of requirements. There was no claim that they were self-consistent or agreed to by all. But there had to be a start and this was done by February 1975, so the program was under way.
David Fisher acted as the Secretariat for the HOLWG, and so became the one who assembled, sifted, correlated, and integrated the requirements, since during the first couple of years, this was the primary action and output of the HOLWG. Fisher had designed machines at Burroughs and taught at Vanderbilt University, before joining IDA. His position was that of the technical heart of the project. It would be improper to say that he "wrote" the requirements, since this was an integration effort of Service needs with worldwide technical input. However, he that produced the final requirements documents; these were his offspring.
The resulting document, entitled STRAWMAN [HOLWG, 1975a], was forwarded to the Military Departments, other government agencies, the academic community, and industry. Additionally, a number of technical experts outside the United States were solicited for comments. The European community was especially responsive, particularly valuable since language research had been more active there than in the United States over the previous decade. ONR London paid several academics (Dijkstra, Hoare, Wirth, ...) to provide inputs, but we got more valuable aid from European industry.
A May 1975 DDR&E memo [Currie, 1975b] (Figure 2) reaffirmed the HOLWG goals to define and implement the minimum number of HOLs to satisfy the needs of the DoD and spelled out a program to evaluate candidates and prove the feasibility of meeting requirements, followed by implementation. The Military Departments were tasked to fund these efforts.

Figure 2

DIRECTOR OF DEFENSE RESEARCH AND ENGINEERING
WASHINGTON, D. C. 20301

                                                           2 MAY 1975

MEMORANDUM FOR Assistant Secretary of Defense (Comptroller)
               Assistant Secretary of Defense (I&L)
               Assistant Secretaries of the Military
                 Departments (R&D)
               Director, Telecommunications and Command
                 and Control Systems

SUBJECT: DoD Higher Order Programming Language Working Group


This is to update you on the progress of the DoD Working Group on Higher
Order Programming Languages.  This group, composed of OSD members and
designated representatives of the Services, was established pursuant to
my memo of 28 January 1975.  Their goal is to establish a minimal number
of common higher order programming languages for utilization throughout
the DoD.  In the past, the multitude of pertinent DoD applications has
caused a proliferation of special languages and, with them, excessive
and extensive software costs.

The first step in attaining the goal of the Working Group is to firmly
establish the requirements for higher order languages from all possible
users, even those for applications which are believed to have
programming requirements not satisfied by any existing higher order
language.  Detailed requirements from those programs which use the
existing common languages, COBOL and FORTRAN, are also desired, although
there is no intent to supersede these languages.

To initiate this process, the Working Group has drawn up a requirements
"strawman", i.e., a list of possible requirements which, while
indicative of the thinking of the committee, are primarily illustrative
of the level of information needed.  This strawman provides the Service
representatives on the Working Group with a definitive example to use in
their subsequent inquiries with users.  A number of the requirements in
the strawman have been selected to be provocative in order to stimulate
comment.  An additional purpose of the strawman is to elucidate the
differences between objectives (economy and readability), requirements
(the minimum primitive operators or capabilities for parallel
processing), and features (which distinguish individual languages, but
are not necessarily fundamental requirements).

The Working Group intends to distribute a request to all possible users
for inputs so that the eventual common language/languages resulting from
this effort will be directly keyed to foreseeable programs.

I request that you give all possible assistance to the Service
representatives of the Working Group when they solicit such inputs.  It
is expected that these inputs will be informal initially, but
eventually, a consolidated and coordinated official input will be
required from each Service.

                                          Malcolm R. Currie

Attachment
DoD HOL Strawman

As a result of the widespread review of the STRAWMAN, the HOLWG received input and commentary from individuals and organizations representing many different areas of application within the DoD. There were mixed reviews. Some said it was too specific, others that it was too vague. So we knew we were on the right trail. The input and comments received by the HOLWG were codified and merged into a more complete, but still tentative set of language requirements. This document was entitled the WOODENMAN [HOLWG, 1975b], and it, in turn, was widely distributed for comment. Note that the thrust of the project at this time was to measure and compare language candidates. WOODENMAN was 88 typed pages and contained considerable description of project goals, as well as the desired characteristics of languages to support these goals. The following text example from WOODENMAN show the level of the document. Figure 3 illustrates a discussion of conflicts between goals and the proposed weighting and resolution. Figure 4 gives a few examples of the required characteristics.

Figure 3.
Example from WOODENMAN - Conflicts in Criteria

B. PROGRAMMING EASE VS. SAFETY FROM PROGRAMMING ERRORS

There is a clear tradeoff between programming ease and safety. The more tolerant the programming language and the less it requires in specifications of the intent and assumptions of the programmer, the easier the coding task. A language which does not require declaration of variables, permits any type of structure of data to be used anywhere without specification, allows short cryptic identifiers, has large numbers of default conventions and coercion rules to permit the use of any operator with any operand, and is capable of assigning meaning to most strings of characters presented as a program will be very easy to use, but also easy to abuse. Safety from errors is enhanced by redundant specifications, by including not only what the program is to do, but what are the author's intentions. and under what assumptions. If everything is made explicit in programs with the language providing few defaults and implicit data conversions, then translator can automatically detect not only syntax errors but a wide variety of semantic and logic errors. Considering that coding is less than one sixth the total programming effort and that there are major software reliability and maintenance problems, this tradeoff should be resolved in favor of error avoidance and against programming ease.

C. OBJECT EFFICIENCY VS. PROGRAM CLARITY AND CORRECTNESS

Two apparently opposing views have been suggested. One, that a simple analysis of either development or life cycle costs shows that reliability, modifiability and maintainability are the most important factors and consequently clarity and correctness of programs must be given consideration over efficiency of the object code which only increases the cost of computer hardware (which is relatively cheap compared to software). In fact, if programs need not work correctly they can easily be implemented with zero cost. The other view points out real problems and applications within DOD software in which the machine capability is fixed and in which object code efficiency is of utmost importance and must be given preference over other considerations.

These views are not inconsistent with regard to the effort on programming language selection. In the vast majority of cases clarity and correctness is more important that is object code efficiency and the programming language should do the utmost to aid the programmer in developing correct and understandable programs within constraints of reasonable object efficiency. In most cases language features which improve clarity do not adversely affect efficiency. In many cases additional information supplied to clarify a program may permit the compiler to use optimizations not applicable in more general cases. There remain, however, special situations in which efficiency is critical. The language should not prohibit access to machine features necessary to accomplish those optimizations when the need arises. Thus, the major criteria in selecting a programming language should be clarity and correctness of programs within the constraint of allowing generation of extremely efficient object code when necessary.

Figure 4. Example from WOODENMAN - Needed Characteristics

K. SYNTAX

1. The source language should be free format, should allow the use of mnemonically significant identifiers, should be based on conventional forms, should be simple uniform and probably LR(1), should not provide unique notations for special cases, and should not permit abbreviation of identifiers or keywords.

Clarity and readability of programs should be the primary criteria for selecting a syntax. Each of the above points can contribute to program clarity. The use of free format, mnemonic identifiers and conventional forms allows the programmer to use notations which have their familiar meanings, to put down his ideas and intentions in order and form that humans think about them, and to transfer skill she already has to the solution of the problem at hand. A simple uniform language reduces the number of cases which must be dealt with by anyone using the language. If programs are difficult for the translator to parse, they will be difficult for people. Similar things should use the same notations with the special case processing reserved for the translator and object machine. The purpose of mnemonic identifiers and key words is to be informative and increase the distance between lexical units of programs. The use of abbreviations eliminates these advantages for a questionable increase in coding ease.

2. The user should not be able to modify the source language syntax. Specifically, he should not be able to modify operator hierarchies, introduce new precedence rules, define new word forms of define new infix operators.

If the user can change the syntax of the language then he can change the basic character and understanding of the language. The distinction between semantic extensions and syntactic extensions is similar to that between being able to coin new words in English or being able to move to another natural language. Coining words requires learning those new meanings before they can be used but at the same time increases the power of the language for some application area. Changing the grammar (e.g., using French) however, undermines the basic understanding of the language itself, changes the mode of expression, and removes the commonalities which obtain between various specializations of the language. Growth of a language through definition of new data and operations and the introduction of new words and symbols to identify them is desirable but there should be no provision for changing the structure of the language. The language should, of course, provide sufficiently general forms that they can be adopted to new possibly unforeseen situations. Neither does this preclude associating new meanings with existing infix operators.

3. The syntax of source language programs should be composable from a character set suitable for publication purposes, but no feature of the language should be inaccessible using the 64 character ASCII subset.

A common language should use notations and a character set convenient for communicating algorithms, programs, and programming techniques among its users. On the other hand, the language should not require special equipment (e.g., card readers and printers) for its use. The use of the 64 character ASCII subset will make the language compatible with the Federal information processing standard 64 character set, FIPS-1, which has been adopted by the U.S.A. Standard Code for Information Interchange (USASCII).

4. The language definition should provide the formation rules for identifiers and literals. These should include a language defined break character for use internal to identifiers and literals.

. . .

A third generation set of requirements was subsequently produced, the TINMAN [HOLWG, 1976] of January 1976. TINMAN was synthesized from the formally stated requirements of the Military Departments, submitted to DDR&E by the respective Service Assistant Secretaries for Research and Development and worldwide technical input. It was formally blessed by the Services. The stated characteristics provided a design philosophy, indicated general structure, and constrained certain detailed properties of the common language; but they did not identify specific language features, consider the tradeoffs among various design and implementation mechanisms, nor demonstrate the feasibility of achieving all the characteristics simultaneously. TINMAN retained some discussion of goals, and Figure 5 provides and example. The format for the needed characteristics is illustrated in Figure 6, which is closer to a requirement specification, but with discussion. At this point we had a fairly firm grip on the problem, further versions were to be refinements.

Figure 5. Example from TINMAN - General Goals

READABILITY/WRlTABILITY

The other major advantage initially claimed for high order languages was that they were easier to read and write, being closer to natural language than is machine code. Claims in this direction were sometimes carried to an extreme and some were promoted so highly that their advocates would have you believe that the coder need not know anything about the machine, simply write out the requirements in English. History does not always support these claims. Many such languages advocated on this basis now are the ones who have the most specialized programmers as their users. The DoD environment is sufficiently large and specialized that the allocation of personnel specifically for software is the rule anyway and there is no strong requirement to eliminate other specialists in this area. This is in contradistinction to a very small commercial firm which may have insufficient demands to justify a full-time programming staff.

Our requirement for readability and writability is therefore primarily among specialists. The desire to communicate with a computer system in natural language is an entirely different one in the DoD and involves query languages or applications programs outside the scope of this high order language effort.

Readability is clearly more important to the DoD than writability. The program is written once, but may have to be read dozens of times over over a period of years !or verification, modification, etc. This is certainly true all weapons systems applications and even most of our scientific and simulation programs are very long lived. This requirement is very much different from one which might be generated, for instance, in a university environment when a program may have a life of only a few months and a single person working on it.

Ease of writing is not an inconsiderable goal but one which may be promoted through intelligent terminals, preprocessors, interactive systems, etc. The language evaluation should favor readability where conflict arises.

Figure 6. Example from TINMAN - Needed Characteristics

H. SYNTAX AND COMMENT CONVENTIONS

1. General Characteristics 2. No Syntax Extensions 3. Source Character Set 4. Identifiers and Literals 5. Lexical Units and Lines 6. Key Words 7. Comment Conventions 8. Unmatched Parentheses 9. Uniform Referent Notation 10. Consistency of Meaning

: H1. The source language will be free format with an explicit statement delimiter, will allow the use of mnemonically significant identifiers, will be based on conventional forms, will have a simple uniform and easily parsed grammar, will not provide unique notations for special cases, will not permit abbreviation of identifiers or key words, and will be syntactically unambiguous.

Clarity and readability of programs will be the primary criteria for selecting a syntax. Each of the above points can contribute to program clarity. The use of free format, mnemonic identifiers and conventional forms allows the programmer to use notations which have their familiar meanings to put down his ideas and intentions in the order and form that humans think about them, and to transfer skills he already has to the solution of the problem at hand. A simple uniform language reduces the number of cases which must be dealt with by anyone using the language. If programs are difficult for the translator to parse they will be difficult for people. Similar things should use the same notations with the special case processing reserved for the translator and object machine. The purpose of mnemonic identifiers and key words is to be informative and increase the distance between lexical units of programs. This does not prevent the use of short identifiers and short key words.

: H2. The user will not be able to modify the source language syntax. Specifically, he will not be able to modify operator hierarchies, introduce new precedence rules, define new key word forms or define new infix operator precedences.

If the user can change the syntax of the language, then he can change the basic character and understanding of the language. The distinction between semantic extensions and syntactic extensions is similar to that between being able to coin new words in English or being able to move to another natural language. Coining words requires learning those new meanings before they can be used, but at the same time increases the power the language for some application areas. Changing the grammar, (e.g., Franglais, the use of French grammar with interspersed English words) however, undermines the basic understanding of the language itself, changes the mode of expression, and removes the commonalities which obtain between various specializations of the language. Growth of a language through definition of new data and operations and the introduction of new words and symbols to identify them is desirable, but there should be no provision for changing the grammatical rules of the language. This requirement does not conflict with E4 and does not preclude associating new meanings with existing infix operators.

: H3. The syntax of source language programs will be composable from a character set suitable for publication purposes, but no feature of the language will be inaccessible using the 64 character ASCII subset.

A common language should use notations and a character set convenient for communicating algorithms, programs, and programming techniques among its users. On the other hand, the language should not require special equipment (e.g., card readers and printers) for its use. The use of the 64 character ASCII subset will make the language compatible with the federal information processing standard 64 character set, FIPS-1, which has been adopted by the U.S.A. Standard code for Information Interchange (USASCII). The language definition will specify the translation from the publication language into the restricted character set.

: H4. The language definition will provide the formation rules for identifiers and literals. These will include literals for numbers and character strings and a break character far use internal to identifiers and literals.

. . .

One significant point agreed to was that the requirements for all Services and applications addressed were consistent with a single language. Up to this point there had been an argument about "the minimum number of languages". There was a general concern that, while a single common language was a goal, it was not technically feasible. The requirements exercise addressed this as a major consideration. We had been faced with the universal, and very strongly stated, opinions of the Services that different user communities had fundamentally different requirements with insufficient overlap to permit a common language among them. Such communities included avionics, weapons guidance, command and control, communications, training simulators, etc. In addition to the embedded computer applications, even the scientific and the financial management communities were solicited for requirements for the sake of completeness. The surprising result was that the requirements so generated were identical. It was impossible to single out different sets of requirements for different communities. All users needed input/output, real-time capability, strong data typing for compiler checking, modularity, etc. Upon reflection, the reason for this was clear; the surprise was historical, stemming from the observation that previously the different communities had adopted different language approaches. Further investigation showed that the origin of this disparity was primarily administrative rather than technical. The Navy was organized into branches for the employment of airplanes, surface ships, and submarines. The Air Force had ground electronics systems (ESD), aircraft systems (ASD), and space systems (SAMSO). Each thought it had to have its own special language. Upon this discovery, the result that a single set of requirements would satisfy a broad set of users became less of a surprise. This did not, however, establish that a single language could meet all the stated requirements, only that a language meeting all of the requirements would satisfy the users' needs.
Also for TINMAN we properly began computer automation. This and all subsequent documents were machine processed and printed on a "laser printer" (Xerox XGP), high tech in 1975. DARPA had the hardware to handle this. Also through DARPA, as the OSD agent, HOLWG was officially authorized mail franking privileges. The combination of these conveniences made it possible for the HOLWG to rapidly disseminate information and documents.
During 1976, the TINMAN was subjected to a thorough review for consistency and technical feasibility. The document was circulated to more than 1,000 individuals in the industrial and academic communities. An international workshop was held at Cornell University in the fall of 1976 [Williams, 1977] to illuminate the current state-of-the-art of programming language design and implementation. In January, 1977, a new version was issued called the IRONMAN [HOLWG, 1977b]. This was much the same set of requirements as the TINMAN, modified slightly for consistency, feasibility, and clarity, but presented in an entirely different format. The TINMAN was discursive and organized around general areas of discussion. The IRONMAN, on the other hand, was very brief and organized like a language manual. It was essentially a specification with which to initiate the design of a language, still sufficiently general so as not to constrain a particular structure of the language, but to define its capabilities. The IRONMAN was revised in July, 1977 [HOLWG, 1977d], mainly to clarify the intent, but also to correct the few errors and inconsistencies that had been identified.
The requirements documents can be viewed as an evolving series. The early ones have a great deal of explanation about the program, motivation and explanation. Those that were following the program presumably followed the evolving arguments, and the versions might be considered cumulative in that sense. There was a rationale for each requirement; early on the documents concentrated on the goals, whereas later the rationales were primarily technical discussions expanding on the implications of the specific requirements.
Requirements decisions made in 1975 proved essentially correct, and remained valid for more than a decade. Fixed point, goto, and the selected character set were requirements that were questioned outside the DoD, but supported inside. Fixed point may now be obsolescent as a result of the cheap hardware implementing the IEEE floating point standard [IEEE, 1985]. The goto is essentially never used, but causes no harm. A more extensive standard character set is only now becoming a possibility.
Foreign Relations
This project from the beginning was considered to be international in scope. It was recognized that Europe had much to contribute technically, and that successful outcome to the effort would be as useful to European military and industrial computing as it would to that of the United States. LTC Philip H. Enslow of the Army Research Office in London set up an Army Programming Conference in April 1975 attended by European computer scientists, including C. A. R. Hoare, Jacob Palme, David Parnas, Ian Pyle, John Webb, and Brian Wichmann, to provide input to the HOLWG effort.
LCDR David C. Rummler from the European branch of the Office of Naval Research facilitated our early European contacts and meetings and eventually returned to the United States to serve on the HOLWG.
The most successful national common language effort to date was that of the British Ministry of Defence (MOD) in specifying the language CORAL 66 for all MOD real-time applications. From extensive interchanges with the MOD, the HOLWG received invaluable technical and managerial insight into a major national language standardization effort. Furthermore, the MOD assigned Philip Wetherall, a senior technical expert, to be resident in Washington providing both technical input to the HOLWG and liaison with the MOD. Wetherall's contribution was particularly important since he was there during the critical period in the evolution of the requirements.
The MOD also provided a two week course in Washington on the CORAL 66 language and its implementations to members of the HOLWG and its contractors, giving valuable insight into a particularly successful program. As part of this cooperative effort, MOD made available CORAL compilers resident on a computer located at the Royal Signals and Radar Establishment (RSRE, Malvern) in the United Kingdom, but accessible through the ARPANET for the use of US evaluation teams. The ARPANET connection was inaugurated during a visit to RSRE by Queen Elizabeth II. Her Majesty sent a message of greetings to the members of the HOLWG from her net account, EIIR, by pressing a red velvet Royal carriage return. Since the address list was long, it took about 45 seconds for the confirmation to come back, 45 seconds of dead air. Prince Philip remarked, joking respectfully, that it looked like she broke it.
The International Purdue Workshops (IPW) on Industrial Computer Systems, chaired by Professor Ted Williams, was another group that was working in the same area. It is interesting to note how many independent efforts we found, once we had established the program. I believe that the wide publicity of the DoD program enabled us to bring together the talents of those who were working in the various independent communities, to the benefit of all. We contacted Williams on the commendation of a Navy official, who had been his roommate in college. Their subgroup, Long-Term Procedural Language, especially the European branch, LTPL-E, had as a goal the generation of a language much like the proposed DoD HOL. The Commission of the European Communities (CEC) had adopted the concept of a common international industrial language for the European Economic Community (EEC). There was an active relationship between the LTPL-E and the EEC and the HOLWG. LTPL-E was closely analogous to the HOLWG in trying to satisfy the requirements of a number of sovereign countries with diverse application areas. It was at a EEC sponsored LTPL-E meeting that I first met Dr. Jean Ichbiah. He became interested and involved in the program, and the eventual winner of the design competition. In October 1977, the International Purdue Workshops resolved to cooperate fully with the HOLWG program. In November 1977, Christopher Layton, Director, Science and Technology Directorate, CEC, announced at an international conference that the CEC would evaluate the HOLWG efforts for adoption.
The International Standards Organization (ISO) set up a Working Group (Programming Languages for Industrial Processes - TC 97/SC 5/WG 1) on real-time languages at about this time. The early thrust was to establish a standard for real-time FORTRAN, but the Group included an international group of experts in the area, who were invited to participate in the HOLWG effort. They made enormous contributions to the program. The technical body representing the American National Standards Institute (ANSI) in forming WG 1 was the US portion of IPW.
The German and French governments initiated procedures to standardize on existing high order languages, PEARL and LTR respectively, in a move similar to DoD's establishment of approved HOLs in 5000.31. HOLWG involved the people responsible for these languages and they supported us unselfishly, in spite of the prospect of our program competing with theirs.
The Japanese government, through its Ministry of Information Technology and Industry, subsidized a consortium of the computer industry to produce a software production environment, central to which was to be a common programming language, CTL-B. The Comite Consultatif International Telegraphique et Telephonique (CCITT) developed a common high order language for international use in communications. This was done at the same time as the HOLWG effort, and I was told off-line by members of the developing committee that they made a policy not to communicate with the competition. In any case they never answered any of my letters. CHILL was the product of that development.
Just to keep things legal, the US State Department was consulted on all of the HOLWG international contacts and advised on the progress of the program. One has to proceed with due care in Washington. We made it clear that this was an open effort and responded to all correspondence. Several on our mailing list were from behind the Iron Curtain, although we did not get any official queries from the USSR at that time.
Administrative Action
The scope of the project went beyond the technical aspects of languages and included direction to the Services and the follow-on of language control and implementation. To start with, we had to lay the groundwork leading to the adoption of a common language for the DoD. First we established the principle that the use of high order language was advantageous and technically feasible (not a trivial selling job in itself since the vast majority of weapons system code was being done in assembly language, or a covering HOL with most of the code in embedded assembly language), and that standardizing on a minimum number of DoD HOLs was a reasonable goal. Given this premise and the several Service language programs, it was prudent to stop all other language work to concentrate on the one program. This is the sort of position that has an overwhelming force of logic and to which everyone must acquiesce. However, this does not mean that they will go out of their way to support it, or indeed that they will not oppose it.
The first administrative action was the issuing of DoD Directive 5000.29 (April 26, 1976) [DoD, 1976b] which specified that "DoD approved high order programming languages will be used to develop Defense systems software unless it is demonstrated that none of the approved HOLs are cost effective or technically practical over the system life cycle...Each DoD approved HOL will be assigned to a designated control agent ...". Thus, the use of high order languages was established and indeed very strongly mandated, since life cycle costs are usually dominated by maintenance where the high order languages have considerable advantage over assembly language. Only approved high order languages were to be used, thereby reducing the proliferation; and further, these languages were to be controlled by central facilities.
DoD Instruction 5000.31 (November 1976) [DoD, 1976c], "Interim List of DoD Approved High Order Programming Languages", designated the "approved" languages called for by 5000.29 and assigned control responsibility. (Note that this was the "interim" list. The declared intention was to reduce to the DoD common language(s).) COBOL and FORTRAN would be controlled by the Office of the Assistant Secretary of Defense (Comptroller) acting with the National Bureau of Standards and the American National Standards Institute, TACPOL by the Army, CMS-2 and SPL/1 by the Navy, and JOVIAL J3 and J73 by the Air Force. All these languages were exactly those nominated by the Services. This is an example of how things work. We wanted to reduce the number of languages from several hundred to a handful. The only way to not argue forever and lose the moment was to let the Services have their way on their own selections unrestrained. The resulting list may have been flawed [Whitaker, 1990], but you go along to get along.
Formalization of these languages was a major step forward and recognized for the first time the corporate commitment of the Department of Defense to provide support for languages in the long term. It stopped the proliferation of languages in that all new systems were to be programmed in one of these languages, but there was no intent that already existing programs be redone or that the projects change if already committed to a language. There were limitations. The languages themselves were selected from the then-present Service inventories and were not modern powerful languages. They were generally deficient in the areas of tools and in availability of compilers. Further, only the seeds of control were established here. It would be some time before we reached the goal a of well-supported and controlled language. The direction of the program was reported to the Military Departments in a 10 May 1976 memo from DDR&E [Currie, 1976] (Figure 7), which also authorized and requested funds for the next phase.

Figure 7

DIRECTOR OF DEFENSE RESEARCH AND ENGINEERING WASHINGTON, D. C. 20301 10 MAY 1976 MEMORANDUM FOR THE ASSISTANT SECRETARIES OF THE MILITARY DEPARTMENTS (RESEARCH AND DEVELOPMENT) SUBJECT: DoD High Order Language Program References: a. My memos on Software and DoD Higher Order Programming Language, dated 3 December 1974, 28 January 1975, 2 May 1975 b. DoD Directive "Management of Computer Resources in Major Defense Systems" To reduce the high and rising costs of software programs in weapon systems, the referenced memoranda (a) formed a Software Steering Com- mittee to study the problem; (b) established a High Order Language (HOL) Working Group to provide maximum DoD software commonality; (c) stopped implementation of new high order programming languages; and (d) estab- lished a program to delineate software requirements. The following guidance is provided to clarify the present goals and status of the program, and to indicate appropriate directions for the continuation of this program. o The present goal is to define and implement the minimum number of high order languages that will satisfy the needs of the various DoD communities. o Other work in progress to improve present high order languages can continue, in contrast to work on implementing new high order languages, which is to be discontinued. o The first phase of this program has now been completed with the merging of Service requirements, as provided by your memoranda, into a consolidated DoD set. This document is attached. o The second phase of the program will consist of evaluating (1) various candidate language approaches against these requirements, and (2) the feasibility of modifying the language forms to meet these requirements. o The third phase of this program will consist of a six month effort of $1.8 million to present preliminary specifications for common language selection. o The final phase will involve the implementation of these selections. I request that $300,000 of FY 76/7T funds be made available by each Military Department to address the second phase of this program. This phase consists of a program of four month's duration in which at least two programs will be issued by each Military Department to perform this work. A dozen existing languages, selected by the Services, will be included, and each contractor will study several languages such that each language will be covered by at least two contractors. At the com- pletion of this phase, I request that the Working group and technical representatives of the Military Departments evaluate and recommend, via the Management Steering Committee for Embedded Computer Resources, the minimum language approaches that will satisfy the Defense requirements. Until a set of new high order languages are developed under this pro- gram, language proliferation should be avoided. Accordingly, a set of existing languages will be approved in the interim for new weapon systems as prescribed in DoD Directive. I request that the Military Departments nominate by 1 July 1976 existing high order computer pro- gramming languages for interim approval. Such nomination should include the detailed formal specification of the language, a list of several major current users and a suggested facility for control of the language and its tools. I believe this project is of vital importance in alleviating the current DoD software problem and making possible the management initiatives, technology advances, and fiscal savings which we are looking for in this area. I again call upon your help in keeping this program moving. signed Malcolm R. Currie Attachment: DoD Requirements for High Order Computer Programming Languages cc: DARPA DTACCS ASD(I) ASD(C) ASD(I&L)

Evaluations
The next step, beginning in June 1976, was the evaluation of existing languages against the integrated set of requirements. Ideally, it was expected that the language requirements should be met through selection or modification of existing languages. A number of languages were proposed as potential candidates to meet the common language requirements as stated in the then current Department of Defense Requirements for High Order Computer Programming Languages "TINMAN" [HOLWG,1976]. Subsequently each of these candidate languages was evaluated to determine the degree of compliance with the TINMAN requirements. In addition, a number of other languages, although not full candidates, were examined because they contained special features and technological innovations.
The languages chosen were:

Widely used, standard languages such as COBOL, FORTRAN, and PL/I.

Languages specifically designed for DoD embedded computer systems applications such as those which were later chosen for the interim standard list (example: TACPOL, CMS-2, J-73), and those widely used elsewhere for similar applications such as HAL/S and CORAL 66.

Those languages which best represented modern computer science techniques such as Pascal, ALGOL 68, and SIMULA 67.

Other languages were also evaluated but in a less formal fashion. They were nominated as "interest items" during the progress of this work, for example, LIS, EUCLID, and RTL-2.

The following languages received formal evaluations: ALGOL 60, ALGOL 68, CMS-2, COBOL, CORAL 66, CS-4, ECL, EUCLID, FORTRAN, HAL/S, JOVIAL J-3B, JOVIAL J-73, LIS, LTR, MORAL, RTL/2, Pascal, PDL/2, PEARL, PL/I, SIMULA 67, SPL/1, TACPOL.
Evaluations were conducted under contracts funded and administered by the Military Departments or by other interested parties such as the British MOD. All candidate languages were evaluated by more than one contractor, and each contractor evaluated several languages, thereby providing a technical crosscheck on the individual evaluations. The general statement of work for all contractors was drawn up by the HOLWG. It specified that for each language requirement, the contractor was to determine the degree of compliance of each of the candidate languages, to comment on the feasibility of modifying the language to bring it into compliance, and to identify features in excess of the requirements. In addition, the statement of work contained a provision for the contractors to comment in detail on the technical feasibility and strength of each requirement, based on their examination of the languages as well as their own corporate experience, to be input for revising the TINMAN. This led to the update of requirements to IRONMAN [HOLWG, 1977b] in January 1977, but the differences between the TINMAN and the IRONMAN were so minor as not to affect the conclusions of the evaluation.
There were also a number of separate formal evaluations made of individual languages by other organizations having unique experience with a particular language, or its designers ("fathers"). In addition, other less formal input included evaluations of requirements different from the TINMAN, examination of special features in certain languages, and briefings and exchange of reports.
Other languages were considered for formal evaluation, but were not included because preliminary examination led one to believe that they would not meet the requirements so were not viable candidates for the purposes of the DoD. One such language was C. At that time DARPA was working with Western Electric/Bell Labs on UNIX, contractually supporting some DARPA contractors and other government facilities using UNIX. It was the evaluation policy to have the owners provide assessments of their own languages, in addition to the contracted evaluations, so HOLWG took advantage of this connection between DARPA and Bell Labs to request their cooperation. When Bell Labs were invited to evaluate C against the DoD requirements, they said that there was no chance of C meeting the requirements of readability, safety, etc., for which we were striving, and that it should not even be on the list of evaluated languages. We recognized the truth in their observation and honored their request.
In January 1977 a report on the consolidation of evaluations was prepared by a subcommittee chaired by Serafino Amorosa, using in-house personnel, the contractors participating in the evaluation, and special consultants [HOLWG, 1977a]. This publication included the complete text of each evaluation report and a resolution of any conflicting reports from contractors evaluating the same language. It provided a summary of the technical evaluations and an assessment of the applicability of each language to the requirements. There was a determination whether any existing candidate so nearly met the requirements as to have it chosen intact, or with simple modifications, and thereby forego a major design phase in the program. The results from the Evaluation Subcommittee were:

Among all the languages considered, none was found that satisfied the requirements so well that it could be adopted as the common language.

All evaluators felt that the development of a single language satisfying the requirements was a desirable goal.

The consensus of the evaluators was that it would be possible to produce a language within the current state-of-the-art meeting essentially all the requirements.

Almost all the evaluators felt that the process of designing a language to satisfy all the requirements should start from some carefully chosen base language.

Without exception, the following languages were found by the evaluators to be inappropriate to serve as base languages for a development of the common language: FORTRAN, COBOL, TACPOL, CMS-2, JOVIAL J-73, JOVIAL J-3B, SIMULA 67, ALGOL 60, and CORAL 66.

Proposals should be solicited from appropriate language designers for modification efforts using any of the languages, Pascal, PL/I, or ALGOL 68 as a base language from which to start. These efforts should be directed toward the production of a language that satisfied the DoD set of language requirements for embedded computer applications.

At some appropriate time, a choice should be made among these design efforts to determine which are most worthy of being continued to completion.

The definition of a base language which evolved during this procedure called for one which was familiar to the community so that a number of contractors could use it as a starting point and provide an audit trail, which could be used by government personnel to compare between contractors. For instance, PEARL or HAL/S could be considered modifications in the PL/I family towards the desired real-time language. This definition did not imply that those deemed inappropriate as a base language were not perfectly adequate for their operational use at the time. Indeed, the presence of COBOL and FORTRAN, to which the DoD has been committed on a long term basis, belied that implication. Nevertheless, these languages would not have been good starting points for a new language since they had basic inconsistencies with the requirements, or had been superseded by more appropriate starting points.
"Base" must be distinguished from languages influencing Ada. There was impact not just in language design but in the requirements:

FORTRAN was significant because that was the successful language - we are still apologizing for FORTRAN features not in Ada (intrinsic math functions (e.g., SQRT, SIN, etc.), interpretive I/O (i.e., with dynamic formatting)), no matter how proper the exclusion;

COBOL pioneered validation - made sure we did not allow the subsets that in 1976 made COBOL systems difficult to validate and compare (may be right for COBOL but not for the purposes of Ada) - data handling, and readability;

JOVIAL and CORAL were languages of major military users whose experiences made considerable contribution to the requirements;

Pascal contributed mostly its syntactic form.

The unanimous recommendations of the evaluation committee, adopted unanimously by the HOLWG were:

That none of the evaluated languages met the requirements to such an extent as to be selected with little or no modifications for a DoD-wide standard;

That it appeared feasible within the state-of-the-art to construct a single language to meet essentially all of the requirements;

That the construction of such a language would most likely be done by modification (albeit substantial) of an existing language. The approaches recommended as a basis for further development were the language families of PL/I, Pascal, and ALGOL-68.

A sidelight on the evaluation was the form of the distributed report. The data consisted of 2600 pages of individual and group reports. They were typed and handwritten, many were on metric sized paper. I felt a responsibility to make sure that everybody involved had a complete record; that was the way the program was run. Conventional methods were impossible; we had no staff or secretarial help for a normal retyping and publication. I took what I know to be an innovative step (since I had to continue to fight for this two years later). I had the whole report put directly on microfiche. (While this may not be the favorite medium in some homes, it is now the media used for most secondary distribution of Government technical documentation. Fiche was the only feasible medium at the time. After 1979, essentially everything was electronic.) I reproduced a sufficient number of copies for the HOLWG distribution and the masters went to the Defense Documentation Center (DDC, now DTIC) for outside requests as [HOLWG, 1977a]. This was bending the system and it took some talking to bring it off, but I thought it was a real breakthrough. The later Phase I and Phase II design evaluations, up to 5600 pages, were also produced only in fiche. There was never what one could call a hard copy document.
After formal adoption of the Program Management Plan by the Management Steering Committee for Embedded Computer Resources, the recommendations of the evaluation committee, the IRONMAN requirements, and the Statement of Work for the language design were forwarded to the MSC-ECS for coordination. This coordination was signed at an MSC-ECS meeting on 31 January 1977.

CONTENTS