Preface

The Department of Defense Common High Order Language program was established in 1975 with the goal of establishing a single high order computer programming language appropriate for DoD embedded computer systems. A High Order Language Working Group (HOLWG) was established to formulate the DoD requirements for high order languages, to evaluate existing languages against those requirements, and to implement the minimal set of languages required for DoD use. As an administrative initiative toward the eventual goal, DoD Directive 5000.29 provides that any new defense systems should be programmed in a DoD approved and centrally controlled high order language. DoD Instruction 5000.31 gives an interim list of approved languages: COBOL, FORTRAN, TACPOL, CMS-2, SPL/1, and JOVIAL J3 and J73. Economic analyses that were used to quantify the benefits from increased use of high order languages, also showed that the rapid introduction of a single modern language would increase the benefits considerably. The requirements have been widely distributed for comment throughout the military and civil communities, producing successively more refined versions from Strawman through Woodenman, Tinman, Ironman, and the present Steelman. During the requirement development process, it was determined that the single set of requirements generated was both necessary and sufficient for all major DoD applications. Formal evaluation was performed on dozens of existing languages concluding that no existing language could be adopted as a single common HoL for the DoD but that a single language meeting essentially all the requirements was both feasible and desirable. Four contractors were funded to produce competing prototype designs. After analysis of these preliminary designs the number of design teams was reduced to two. Their designs will be completed and a single language will emerge. Further steps in the program will include test and evaluation of the language, production of compilers and other tools for software development and maintenance, control of the language, and validation of compilers. Government-funded compilers and software tools, as well as the compiler validation facility, will be widely and inexpensively available and well maintained.

Requirements

The technical requirements for a common DoD high order programming language given here arc a synthesis of the requirements submitted by the Military Departments. They specify a set of constraints on the design of languages that are appropriate for embedded computer applications (i.e., command and control, communications, avionics, shipboard, test equipment, software development and maintenance, and support applications). We would especially like to thank the phase one analysis teams, the language design teams, and the many other individuals and organizations that have commented on the Revised Ironman and have identified weaknesses and trouble spots in the technical requirements. A primary goal in this revision has been to reduce the complexity of the resulting language.

This revision incorporates the following changes. Care has been taken to ensure that the paragraph numbers remain the same as in the Revised Ironman. There have been several changes in terminology and many changes in wording to improve the understandability and preciseness of the requirements. Several requirements have been restated to remove constraints that were unintended but were implied because the requirement suggested a particular mechanism rather than giving the underlying requirement. The requirements for embedded comments (2I), unordered enumeration types (3-2B), associative operator specifications (7D), dynamic aliasing of array components (10B), and multiple representations of data (11B) have been deleted because they have been found unnecessary or are not adequately justified. The minimal source language character set has been reduced to 55 characters to make it compatible with the majority of existing input devices (See Section 2A). The do together model for parallel processing-has been found inadequate for embedded computer applications and has been replaced by a requirement for parallel processes (See Section 9). The preliminary designs have demonstrated the need for additional requirements for explicit conversion between types (See Section 3B), subtype constraints (See Section 3D), renaming (See Section 3-5B), a language distinction between open and closed scopes (See Section 5G), and the ability, but preferably not special mechanisms, to pass data between parallel processes (See Section 9H), to write nonverifiable assertions (See Section 10F), to wait for several signals simultaneously (See Section 9J), and to mark shared variables (See Section 9C).

The Steelman is organized with an outline similar to that expected in a language defining document. Section 1 gives the general design criteria. These provide the major goals that influenced the selection of more specific requirements in later sections and provide a basis for language design decisions that are not otherwise addressed in this document. Sections Section 2 through Section 12 give more specific constraints on the language and its translators. The Steelman calls for the inclusion of features to satisfy specific needs in the design, implementation, and maintenance of military software, specifies both general and specific characteristics desired for the language, and calls for the exclusion of certain undesirable characteristics. Section 13 gives some of the intentions and expectations for development, control, and use of the language. The intended use and environment for the language has strongly influenced the requirements, and should influence the language design.

A precise and consistent use of terms has been attempted throughout the document. Many potentially ambiguous terms have been defined in the text. Care has been taken to distinguish between requirements, given as text, and comments, given as bracketed notes.

The following terms have been used throughout the text to indicate where and to what degree individual constraints apply:

shall

indicates a requirement placed on the language or translator

should

indicates a desired goal but one for which there is no objective test

shall attempt

indicates a desired goal but one that may not be achievable given the current state-of-the-art, of may be in conflict with other more important requirements

shall require

indicates a requirement placed on the user by the language and its translators (language is subject)

shall permit

indicates a requirement placed on the language to provide an option to the user (language is subject)

must

indicates a requirement placed on the user by the language and its translators (user is subject)

may

indicates a requirement placed on the language to provide an option to the user (user is subject)

will

indicates a consequence that is expected to follow or indicates an intention of the DoD; it does not in any case by itself constrain the design of the language

translation

refers to any processing applied to a program by the host or object machine before execution; it includes lexical analysis, syntactic error checking, program analysis, optimization, code generation, assembly, and loading

execution

refers to the processing by the object machine to carry out the actions prescribed by the program.