Definitions     Table of Contents
Source Language     Translator     Management Controls     Compile Time     Run-Time     Authors
Webpage Note

The following is a strawman list of requirements for the common DoD High Order Language (HOL). It is the understanding of the subcommittee that the common HOL should support software development and maintenance for all DoD applications and will eventually supplant all programming languages used by DoD except COBOL and FORTRRAN. The strawman list was derived from the initial lists submitted by the individual Military Departments.

This subcommittee believes that there are both operational and technological requirements for the common HOL. Each requirement appears on the strawman list for at least one of the following reasons:

1. the requirement appeared on all of the initial requirements lists and was in conflict with no other requirement:

3. the requirement takes a strong position on one side or the other of a controversial issue;

4. the requirement reveals an issue or an aspect of HOLs where there are likely to be requirements.

The purpose of this strawman is to aid the services in formulating their HOL requirements. It is our understanding that existing languages will be evaluated against the resulting requirements.

Each service is expected to respond with its own list of requirements. It is our belief that each requirement should be brief and address a single issue. Requirements should be sufficiently precise so that the question "does language X meet this requirement" is answerable. Requirements should express a need rather than a mechanism for meeting that need. Thus an attempt should be made to replace each initial requirement by the specific underlying need. It is obvious that the strawman does not fully meet these goals.

Each requirement should be traceable. That is, the operational or technological source of the requirement should be given with the requirement. For operational requirements, the trace should include why it is needed and a list of where it is needed. For technological requirements the trace should include why it is needed and references to related work.

DEFINITIONS

USER	User of the language; i.e., the programmer.
TYPE	A sequence or set of elements which share common properties and operations.
VARIABLE	A dynamically valued container.
SCALAR	A value which has no internal structure which cannot be modified by the user. That is, a scalar is a constant.
ARRAY	An indexed set of variables of bounded size.
RECORD	A labeled set of variables.
FIXED	Means completely determined at the time of translation and not modifiable at run time.
DYNAMIC	Means that the property can be changed at run time under program control.
OPEN ROUTINE	A routine that can be inserted directly into a larger routine without a linkage or calling sequence.
CLOSED ROUTINE	A routine which is not inserted as a block of instructions within a main routine, but is entered by basic linkage from the main routine.

COMMON HOL REQUIREMENTS

I.   SOURCE LANGUAGE

I.A  Character Set I.A.1   Types I.A.2   Variables I.A.3   Parameters

I.B  Operations

I.C  Control Structures

I.D  Syntax I.D.1   Parsing Rules I.D.2   Lexical Structure I.D.3   Character Set

I.E  Scope Rules

I.F  Specification I.F.1   Variable Specifications I.F.2   Notes to Translator I.F.3   Insertions I.F.4   Assertions I.F.5   Comments

II.   TRANSLATOR

II.A  Object Code II.B  Compile Time Checks II.C  Compile Time Features

III.   MANAGEMENT CONTROLS

IV.   COMPILE TIME ENVIRONMENT

V.   RUN-TIME ENVIRONMENT

I.  SOURCE LANGUAGE

Every user level aspect of the language will be formally specified. None will be left to the translator implementer, operating system or object machine.

There will be a traceable operational and/or technological requirement for each primitive data, operation and control structure in the language.

The language will not reveal minor differrences in computer architecture.

Machine dependent code cannot appear interspersed in-line in source language programs.

The semantics of the language will be determinable from the description.

Constructs of the language will have only one reasonable interpretation (i.e., physcologically unambiguous).

There will be an axiomatic definition of the language. It will be mathematically complete in the Turing sense.

The language will not sacrifice clarity for efficiency.

The language will not contain special features for rare cases.

All defaults in a program will be specifically provided in the language specification or in the program.

There will be a minimal number of defaults.

I.A  DATA

Dynamic allocation and de-allocation will be explicit. Non-dynamic allocation and de-allocation will be implicit.

I.A.1  TYPES

There will be only primitive types for integer, real (floating or fixed point), Boolean (bit), and character.

The language will provide the capability for defining new data types.

Defined types will be generated by enumeration, cartesian produce, discriminated union, power set, recursive data structure (this subsumes pointers), array of values or sequencing. [Ref: Dahl, O.J.; Dijkstra, E.W.; Hoare, C.A.R.; Structured Programming, April 1972, pp. 91-174.]

Any requirement which applies to primitive types will also apply to defined types.

The use of a particular type is independent of its representation. Thus, the representation can be changed without changing the calling program.

Recursively defined data structures will be preserved over I/O and relocation.

I.A.2  VARIABLES

The type of each variable will be explicitly individually specified in the source program.

Scalar variables, arrays and records will be the only primitive variable structures in the language.

Variables and arrays will be of fixed type.

All variables will be initialized at the time of their allocation. All initial values will be explicitly specified in the program (not necessarily within this program module).

The language will provide for initialization of variables at their definition.

Arrays will be of homogeneous type.

The user will be able to specify array origin.

The number of dimensions for an array will be fixed but not limited by the translator.

The language will support dynamic array size. The default for arrays will be static size.

The language will support records of a heterogeneous type with fixed conditional structure.

I.A.3  PARAMETERS

Formal and actual parameters must agree on type and size and will be checked at translation and binding times.

All capabilities of intrinsic functions will be available to user defined functions. (E.g., the language will support routines with a variable number of arguments.)

Four classes of formal parameters are needed: those which represent the value of the actual parameter at the time of call; those which represent the dynamic value of the actual parameter; those which represent an actual parameter variable which can be assigned to; and those which represent program components other than values or variables (e.g., routines, types, labels, events).

I.B  OPERATIONS

The following primitive arithmetic operators will be provided: addition, subtraction, multiplication, division, exponentiation, and negation.

The following primitive character string operations will be provided: concatenation, substring and length.

The following Boolean operators will be provided: and, or and not.

The language will contain an equivalence and a non-equivalence operator applicable to all data types except those composed from reals.

Relational operators will be provided for all explicitly ordered data types except those composed from reals.

There will be no implicit type conversions except to supersets.

There will be at least one primitive operator for conversion from real to integer.

Scalar operations may be applied to conformable structures to indicate component by component operations.

Assignments will be permitted between conformable variables, arrays or records of the same type, except for implicit type transfers.

Operations for a given type will be definable with the type.

The language will permit extension of existing operators to new types.

There will be the ability to dynamically assign and reassign I/O devices.

I.C  CONTROL STRUCTURES

The language will include control structures for sequential, conditional, iterative, recursive (pseudo) parallel processing and exception handling.

The language will provide for the "go to."

Capabilities to be provided under parallel processing will include: creation, activation, synchronization, and termination of processes.

Conditional structures will be fully partitioned. The results of all possible states of the condition will be explicitly stated.

The user will be able to direct notification of run time errors to appropriate parts of his program(s). This information will include kind, data context, and control context of the error.

The prmitive control structures will have a simple and efficient translation as code in object machines of conventional architecture.

I.D  SYNTAX

The source language will be consistent and free from ambiguity, both syntactically and semantically.

There will be no syntax extension facility.

The language will be expressable in free form.

The syntax will be based on conventional forms.

The language will provide compact notations for frequently used items (e.g., key words should be short).

I.D.1  PARSING RULES

A single interpretation will not be represented by more than one syntactic form.

The language will provide similar notation for similar things.

There will be no syntactic distinction between function calls and data selection.

The user will be able to associate infix and prefix notation with routines.

Literals will have the same syntax and value whether entered in programs or data.

Literals for primitive types will be defined in the language.

There will be no unmatched "parenthesis" (e.g., every "END" must have only one "BEGIN").

I.D.2  LEXICAL STRUCTURE

The language will specify the rules for lexical units (including identifiers).

The language will encourage the use of mnemonically significant identifiers.

Spaces will be significant in the syntax.

There will be a language defined character break for use within names.

End of line will not be internal to lexical units and will have the effect of a space.

Names and literals will not extend beyond the end of line.

All key words will be reserved (i.e., cannot be used as identifiers). Reserved words will be relatively limited in number. All key words will be included in the language specification.

I.A.3  CHAR SET

There will be a standard language defined character set. Characters in this standard character set which are not universally available will have an alternate (universally available) representation.

The language will specify the collating sequence.

I.E  SCOPE RULES

The language will allow the scope of an identifier to be restricted to be restricted to only those sections of programs where it is intended to be used.

The scope of an identifier will be wholly determined at compile time.

Identifiers will be introduced at the beginning of their scope.

Multiple use of identifiers will not be allowed in the same scope except for embedded blocks in which case the inner-most identifier will apply.

A feature will exist in the language which provides the user the capability to specify entities (anything definable in the language) within a scope which are exportable to other scopes. This includes separately compilable scopes.

I.F  SPECIFICATIONS

I.F.1  VARIABLE SPECIFICATIONS

The user will have the capability to explicitly specify the range, precision and scale factor of numeric variables.

The user must specify the default range and precision for variables within his program.

The language will permit specification of units of measure.

I.F.2  NOTES TO TRANSLATOR

The user will be able to specify space/time tradeoff to the compiler. As an example, the user will be able to specify packing of data in a machine independent bit equivalent form.

User can specify whether a routine is open or closed.

I.F.3  INSERTIONS

The user can cause any things in the library to be inserted into his program.

The user can cause separately compiled things to be inserted into his program.

Inserted routines may be written in other language including assembly languages.

I.F.4  ASSERTIONS

The language will allow inclusion of assertions in programs.

I.F.5  COMMENTS

End of line will be the terminator for a comment. The start of a comment will be designated by a language specified single character.

All language specified characters may be included within a comment.

II.  TRANSLATOR

Any translator for the language must implement the entire language (NO subsets).

Any translator for the language must implement only the language as specified (translator implementer may not expand the language specification).

Translator does not have to run on all object machines. Self-hosting is not required.

II.A  OBJECT CODE

The translator will generate efficient object code.

It will be the responsibility of the translator to insure that optimization does not change the effect of the program (i.e., code motion is allowed if it does not change the results).

The translator will not impose run-time costs for unused generalities.

Translator will evaluate constant expressions at compile time.

Translator(s) must be able to produce code for a variety of object machines. (Language features will be machine independent).

Prevention of race conditions and deadlocks on shared data will be guaranteed.

II.B  COMPILE-TIME CHECKS

The types of all variables, expressions, and parameters will be checked for compatability at translation/binding time.

The translator will validate range specifications where possible.

Compatibility of units of measure will be checked whenever possible.

There will be a standard set of compile-time mneumonic diagnostic messages.

II.C  COMPILE TIME FEATURES

The language will provide compile time executable statements. The language of these statements will be identical to the source language. [This includes conditional compilation and debugging statements.)

The user will be able to inhibit code generation.

The translator must provide open and closed routine capabilities.

The translator will be capable of scaling. That is, it will be capable of generating fixed point instructions and managing the scale factors at compile time.

The translator will optionally generate code for run-time checking of range.

III.  MANAGEMENT CONTROLS

Control procedures must be established to ensure translator implementation of the language as specified.

Translator will be able to enforce installation defined programming conventions.

IV.  COMPILE TIME ENVIRONMENT

The library will be capable of holding any named thing definable in the source language.

Any item in the library will be definable in the source language and the concurrent definition must be in the library.

Required data operations and control which are definable in terms of the primitives will be provided in the supported libraries. This may include complex data types, list structures, vectors and matrix operations.

There will be supported libraries for graphics and debugging aids.

The language will support real time clocks and real time events.

V.  RUN-TIME ENVIRONMENT

Run-time errors will be reported in terms of the structure of the source program (this might be in the form of a postprocessor).

There will be a well defined, standard operating system interface.

There will be a well defined, standard data base interface.

There will be a common object data format for transferring records between machines.

There will be dynamic debugging facilities, in terms of the source language, including commands to set and reset breakpoints on any statement in the program, the ability of the system to return control to the user in the event of a program error, facilities for examining and altering any data item in a program once it has been frozen and control returned to the interactive debugging control, the ability to restart the program not necessarily at the point at which execution was interrupted, facilities for deleting, replacing and inserting lines in the program, commands to request statistical information about the behavior of the program, and convenient methods for initiating any of the foregoing facilities.

AUTHORS

James M. Robinette
Quality Assurance Directorate
U.S. Army Computer Systems
Fort Belvoir, Virginia

Martin Wolfe
Computer Software Area
Languages Team
AMSEL-NL-BG-2
Comm/ADP Lab
Fort Monmouth, New Jersey 07703

John Shore
Code 5403, U.S. Naval Research Lab
Washington, D.C. 20375

Warren E. Loper
Code 5200
Naval Electronics Laboratory Center
San Diego, California 92152

David Weiss
Code 5403D
U.S. Naval Research Lab
Washington, D.C. 20375

Thomas H. Jarrell, Maj.
HQAF SC/XRF
Andrews AFB, Maryland

David A. Fisher
Institute for Defense Analyses
400 Army-Navy Drive
Arlington, Virginia 22202