The technical requirements for a common DoD high order
programming language given here are a synthesis of the
requirements submitted by the Military Departments. They specify
a set of language characteristics that are
appropriate for embedded computer applications (i.e., command and
control, communications, avionics, shipboard, test equipment,
software development and maintenance, and support applications).
The changes that produced this revision reflect the many
comments on previous versions received from the Services,
military contractors, the research community, and other
organizations during 1976. This revision does not alter the
basic intent or substance of the December 1975
The revised requirements are hierarchically organized
with an outline similar to that expected in a language
defining document. Section l gives the
general design criteria. These provide the major goals that
influenced the selection of specific requirements and provide a basis for language design decisions that
are not otherwise dealt with in the requirements. Sections 2 through
l2 give more specific technical requirements on the language and its
translators. The requirements call for the inclusion of features to
satisfy specific needs in the design, implementation, and
maintenance of military software, specify many general and
specific characteristics desired for the language, and call for
the exclusion of certain undesirable characteristics. Section l3
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; understanding those intentions should aid in
achieving the requirements.
A precise and consistent use of terms has been attempted
throughout the document. Potentially ambiguous terms have
been defined in the text. Care has been taken to distinguish
between requirements, given as text, and comments about the requirements, given as
bracketed notes. Previously duplicative requirements have been given just once.
Potentially conflicting implications of requirements have been clarified.
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,
or may be in conflict with other more important
requirements
|
|
shall require
|
indicates a requirement that is to be placed on the user by
the language and its translators
|
|
shall permit
|
indicates a requirement placed on the language
to provide an option to the user
|
|
must
|
same meaning as shall require but takes user as subject
|
|
may
|
same meaning as shall permit but takes user as 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
|
Some of the above terms are also used informally in the bracketed notes. Language is used
in the singular to refer to the minimum number of languages necessary to satisfy the needs
of DoD applications.
1. GENERAL DESIGN CRITERIA
1A. GENERALITY
The language shall provide generality only to
the extent necessary to satisfy the needs of embedded computer
applications. Such applications require real time control,
self diagnostics, input-output to nonstandard peripheral
devices, parallel processing, numeric computation, and file
processing.
The language shall not contain features that are unnecessary to satisfy the requirements.
1B. RELIABILITY
The language should aid the design and
development of reliable programs. The language shall be
designed to avoid error prone features and to maximize
automatic detection of programming errors. The language shall
require some redundant, but not duplicative, specifications in
programs. Translators shall produce explanatory diagnostic and
warning messages, but shall not attempt to correct programming
errors.
1C. MAINTAINABILITY
The language should promote ease of
program maintenance. It should emphasize program maintenance.
It should emphasize program readability over writeability. That is,
it should emphasize the clarity, understandability, and modifiability of
programs over programming ease. The language should encourage user documentation of
programs. It shall require explicit specification of
programmer decisions and shall provide defaults only for
instances where the default is stated in the language
definition, is always meaningful, reflects common
usage, and can be explicitly overridden.
1D. EFFICIENCY
The language design should aid the production
of efficient object programs. Constructs that have
unexpectedly expensive or exceptionally inexpensive implementations should be easily
recognizable by translators and by users.
Users shall be able to specify the time space trade offs in a program.
Where possible, features should be
chosen to have a simple and efficient implementation in many
object machines, to avoid execution costs for available
generality where it is not needed, to maximize the number of
safe optimizations available to translators, and to ensure that
unused and constant portions of programs will not add to
execution costs. Execution time support packages of the
language shall not be included in object code unless they are
called.
1E. SIMPLICITY
The language should not contain unnecessary
complexity. It should have a consistent semantic structure
that minimizes the number of underlying concepts. It should be
as small as possible consistent with the needs of the intended
applications. It should have few special cases and should be
composed from features that are individually simple in their
semantics. The language should have uniform syntactic
conventions and should not provide several notations for the
same concept.
1F. IMPLEMENTABILITY
The language shall be composed from
features that are understood and can be implemented. The
semantics of each feature should be sufficiently well specified
and understandable that it will be possible to predict its
interaction with other features. To the extent that it does
not interfere with other requirements, the language shall
facilitate the production of translators that are easy to
implement and are efficient during translation. There shall be
no language restrictions that are not enforceable by
translators.
1G. MACHINE INDEPENDENCE
The language shall
strive for machine independence. It shall not dictate the
characteristics of object machines or operating systems.
The design of the language shall attempt to avoid features whose semantics depend on
characteristics of the object machine or of the object machine
operating system. There shall be a facility for
specifying those portions of programs that are dependent on the
object machine configuration and for conditionally compiling
programs depending on the actual configuration.
1H. FORMAL DEFINITION
To the extent that a formal definition
assists in achieving the above goals,
the language shall be formally defined.
[Note that formal definitions are of most value during language design; and
that the same method may not be appropriate for defining all aspects of a language.]
2. GENERAL SYNTAX
[ RED Reference RED Rationale ]
2A. CHARACTER SET
Every construct of the language shall have a representation that uses only the 64 character subset of ASCII:
2B. GRAMMAR
The language should have a simple, uniform, and
easily parsed grammar and lexical structure. The language
shall have free form syntax and should use familiar notations
where such use does not conflict with other goals.
2C. SYNTACTIC EXTENSIONS
The user shall not be able to
modify the source language syntax. In particular the user
shall not be able to modify or introduce new precedence rules or to
define new syntactic forms.
2D. OTHER SYNTACTIC ISSUES
Multiple occurrences of a
language defined symbol appearing in the same context shall not
have essentially different meanings. The language shall not permit
unmatched parentheses of any kind (e.g., begin and end must be paired
one for one). Source program line boundaries shall be treated like spaces.
All key word forms that
contain declarations or statements shall be bracketed (i.e.,
shall have a closing as well as an opening key word).
2.1. Identifiers
2.1.E. MNEMONIC IDENTIFIERS
Mnemonically significant
identifiers shall be allowed. There shall be a break character
for use within identifiers. The language and its translators
shall not permit identifiers or reserved words to be
abbreviated.
2.1.F. RESERVED WORDS
The only reserved words shall be those
that introduce special syntactic forms or that are otherwise used as
delimiters. Words that can be used in place of identifiers shall
not be reserved (e.g., names of built-in or predefined functions, types, constants,
and the like shall not be reserved). All reserved words shall
be listed in the language definition.
2.2. Literals
2.2.G. NUMERIC LITERALS
There shall be built-in numeric
literals. Numeric literals shall have the same values in programs as in data.
2.2.H. STRING LITERALS
There shall be built-in string literals.
String literals shall be
interpreted as fixed-length one-dimensional character arrays.
Literal strings shall not be allowed to cross line boundaries of the source program.
2.3. Comments
2.3.I. COMMENTS
The language shall allow comments to be embedded within program text (e.g., a comment bracketed by
special left and right bracket symbols) and shall allow stand alone comments (e.g., a comment
introduced by a special symbol at the beginning of each line). Bracket symbols shall consist of no more than
two characters each. The language shall not permit comments to automatically cross line boundaries.
3. TYPES
[ RED Reference RED Rationale ]
3A. STRONG TYPING
The language shall be strongly typed. That is, the type or mode of each variable, array and
record component, expression, function, and parameter shall be determinable at translation time.
The
type of each variable, array and record component, expression,
function, and parameter shall be determinable during
translation.
3B. IMPLICIT TYPE CONVERSIONS
There shall be no implicit conversions between types.
3C. TYPE DEFINITIONS
It shall be possible to define new data
types in programs. Type definitions shall be processed entirely at translation time.
The scope of a type definition shall be determinable at translation time. No restriction shall be
imposed on defined types unless it is imposed on all types.
3.1 NUMERIC TYPES
3-1A. NUMERIC VALUES
The language shall provide types for integer, fixed point, and floating point numbers.
Numeric operations and assignment that would cause the most significant digits of numeric
values to be truncated (e.g., when overflow occurs) shall constitute an exception situation.
3-1B. NUMERIC OPERATIONS
There shall be built-in operations
(i.e., functions) for conversion between numeric types.
There shall be built-in operations for addition, subtraction,
multiplication, division, with floating point result, and negation for
all numeric types. There
shall be built-in equality (i.e., equal and unequal) and
ordering operations (i.e., less than, greater than, less or equal, and greater or equal) between elements of each
numeric type. Numeric values shall be equal if and only if
they represent exactly the same abstract value.
The semantics of all built-in numeric operations shall be included in the language definition.
[Note that there might also be standard library definitions for numeric functions such as
exponentiation.]
3.1.1 Floating Point Type
3.1.1.C. (3-1C.) FLOATING POINT PRECISION
The precision of each floating point variable and expression shall be
specifiable in programs and shall be determinable at translation time.
Precision specifications shall be required for each floating point variable.
Precision shall be interpreted as the minimum precision to be implemented in the object
machine. Floating point results shall be implicitly rounded (or on some machines truncated)
to the implemented precision. Explicit conversion operations shall not be
required between floating point precisions.
3.1.1.D. (3-1D.) FLOATING POINT IMPLEMENTATION
A floating point computation may be implemented using the actual precision, radix, and exponent range available in the
object machine hardware. There shall be built-in operations to access the actual precision, radix, and exponent range
with which floating point variables and expressions are implemented.
3.1.2 Integer and Fixed Point Types
3.1.2.E. (3-1E.) INTEGER AND FIXED POINT NUMBERS
Integer and fixed
point numbers shall be treated as exact numeric values. There
shall be no implicit truncation or rounding in integer and
fixed point computations.
3.1.2.F. (3-1F.) INTEGER AND FIXED POINT VARIABLES
The range of each integer and fixed point variable must be specified in programs and determinable at translation time. Such
specifications shall be interpreted as the minimum range to be implemented. Explicit conversion operations
shall not be required between numeric ranges.
3.1.2.G. (3-1G.) FIXED POINT SCALE
The scale or step size (i.e., the
minimal representable difference between values) of each fixed
point variable must be specified in programs and be
determinable at translation time.
3.1.2.H. (3-1H.) INTEGER AND FIXED POINT OPERATIONS
There shall be
built-in operations for integer and fixed point
division with remainder and for conversion between fixed point
scale values. The language shall require explicit scale conversion operations
whenever the scale of a value must be changed to properly perform some operation (e.g., assignment,
comparison, or parameter passing).
3.2 ENUMERATION TYPES
3-2A. ENUMERATION TYPE DEFINITIONS
There shall be types that
are definable in programs by enumeration of their elements.
The elements of an enumeration type may be identifiers or
character literals. Literal identifiers shall be syntactically distinguishable from
other identifiers. Equality and inequality shall be automatically defined between
elements of each enumeration type.
3-2B. ORDERED ENUMERATION TYPES
Ordered enumeration types must be so marked in their definitions. The four ordering operations shall be
automatically defined between elements of each ordered type defined by enumeration. A variable of an
ordered enumeration type may be restricted to a contiguous subsequence of the enumeration.
3.2.1 Boolean Type
3.2.1.C. (3-2C.) BOOLEAN TYPE
There shall be a predefined unordered enumeration type for Boolean values. The Boolean type shall have operations
for conjunction, inclusive disjunction, and negation.
3.2.1.D. (3-2D.) CHARACTER TYPES
Character sets shall be definable as
enumeration types. Character types may contain both printable
and control characters. Definitions for ASCII and other widely used
character sets shall be available in a standard library.
3.3 COMPOSITE TYPES
3-3A. COMPOSITE TYPE DEFINITIONS
It shall be possible to
define types that are Cartesian products of other types.
Composite types shall include arrays (i.e., composite data with
indexable components of homogeneous types) and records (i.e.,
composite data with labeled components of heterogeneous type).
3-3B. COMPONENT SPECIFICATIONS
For elements of composite
types, the type of each component (i.e., field) must be
explicitly specified in programs and determinable at
translation time. Components may be of any type (including array
and record types). Range, precision, and scale specifications
shall be required for each component of appropriate numeric
types.
3-3C. OPERATIONS ON COMPOSITE TYPES
A value accessing
operation shall be automatically defined for each component of
composite data elements. Assignment shall be automatically
defined for components that have alterable values. A
constructor operation (i.e., an operation that constructs an
element of a type from its constituent parts) shall be
automatically defined for each composite type. An assignable
component may be used anywhere in a program that a variable of
the component's type is permitted.
3.3.1 Arrays
3.3.1.D. (3-3D.) ARRAY SPECIFICATIONS
The number of dimensions for each array must be specified in programs and shall be
determinable at translation time. The range of subscript values for each dimension must be specified
in programs and shall be determinable for the time of array allocation. The range of subscript values shall be
restricted to a contiguous sequence of integers or to a contiguous sequence from an enumeration type.
[Note that translators may be able to produce more efficient object programs where subscript ranges are determinable
at translation time.]
3.3.1.E. (3-3E.) OPERATIONS ON SUBARRAYS
There shall be built-in
operations for value access, assignment, and catenation of
contiguous sections of one-dimensional arrays of the same
component type.
3.3.2 Records
3.3.2.F. (3-3F.) OPERATIONS ON RECORDS
Assignment shall be permitted between records with corresponding components of identical name and type.
3.3.2.G. (3-3G.) NONASSIGNABLE RECORD COMPONENTS
It shall be possible
to specify record components (including tag fields) for which assignment shall not be permitted. These components shall
include those defined as constants and those defined as expressions. [Note that such
components need not take data storage space.]
3.3.2.H. (3-3H.) VARIANT TYPES
It shall be possible to define types with
alternative record structures (i.e., variants). The structure
of each variant shall be determinable at translation time.
Each variant must have a tag field (i.e., component that can be used to
discriminate among the variants during execution). The
value of a variant may be used anywhere a value of the variant type is permitted.
3.3.3 Types Requiring Dynamic Allocation
3.3.3.I. (3-3I.) DEFINITIONS OF DYNAMIC TYPES
It shall be possible to define types
whose elements are dynamically allocated. Elements of such types
may have components of their own type and may have substructure
that can be altered during execution. Such types shall be
distinguishable from other composite types in their
definitions. [Note
that such types require pointers and heap storage
in their implementation. They are intended primarily for the support portions of embedded computer software.]
3.3.3.J. (3-3J.) CONSTRUCTOR OPERATIONS
Each execution of the
constructor operation for a dynamically allocated type shall create a
distinct element of the type. Such elements shall remain allocated as long as there is an access path to them.
3.4 SET TYPES
3-4A. SET TYPE DEFINITIONS
It shall be possible to
define types as power sets of enumeration types. [Note that the elements of such types are sets and can be
implemented as bit strings.]
3-4B. OPERATIONS ON SETS
Membership and constructor operations shall be defined automatically for each type defined as a power set.
Intersection, union, symmetric difference, equality, and inequality shall be automatically defined between
elements of each set type. [Note that intersection, union, and symmetric difference can be
implemented as bit by bit operations for conjunction, inclusive disjunction, and exclusive
disjunction, respectively.]
3.5 ENCAPSULATED DEFINITIONS
3-5A. ENCAPSULATED DEFINITIONS
It shall be possible to
encapsulate definitions. An encapsulation may contain
definitions of the data elements comprising a type and of operations.
3-5B. EFFECTS OF ENCAPSULATION
The effect of encapsulation shall be to inhibit external access to implementation properties of the definition.
In particular declarations made within an encapsulation shall not automatically be accessible outside the
encapsulation. Data elements defined in an encapsulation shall not automatically inherit the operations of
the types with which they are represented.
3-5C. OWN VARIABLES
It shall be possible within encapsulations to declare variables that are accessible only within the
encapsulation but remain allocated throughout the scope in which the encapsulation is declared.
Such variables shall retain their values between entries to the encapsulation. It shall be possible to
initialize such variables at the time of heir apparent allocation.
3-5D. OPERATIONS BETWEEN TYPES
It shall be possible to define operations, like type conversion, that require access to local properties of more than
one encapsulated definition. [Note that thsi capability violates the purpose of encapsulation and thus its use should be avoided
wherever possible.]
4. EXPRESSIONS
[ RED Reference RED Rationale ]
4A. FORM OF EXPRESSIONS
The form (i.e., context free syntax) of expressions
shall not depend on the types of their operands or on whether
the types of the operands are built into the language.
4B. TYPE OF EXPRESSIONS
The language shall require that the type of each expression be determinable at translation time.
It shall be possible to specify the
type of an expression explicitly.
[Note that the latter requirement provides a way to resolve ambiguities in the
types of literals and to assert the type of results; it does
not provide a mechanism for type conversion.]
4C. SIDE EFFECTS
The language should permit few side effects in expressions. In particular, during expression
evaluation assignment shall not be allowed to any variable that is accessible in the scope of the expression.
4D. ALLOWED USAGE
Expressions of a given type shall be
allowed wherever both constants and variables of the type are
allowed.
4E. CONSTANT VALUED EXPRESSIONS
Constant valued expressions (i.e., expressions whose values are determinable at translation time)
shall be allowed wherever constants of the type are allowed. Such expressions shall be evaluated before execution time.
4F. OPERATOR PRECEDENCE LEVELS
The precedence levels (i.e.,
binding strengths) of all infix operators shall be
specified in the language definition, shall not be alterable by
the user, shall be few in number (e.g., three or four), and shall not depend on the
types of the operands. [Note that there might be built-in operator symbols whose meaning is entirely
specified by the user.]
4G. EFFECT OF PARENTHESES
Explicit parentheses
shall dictate the association of operands with operators. Explicit parentheses shall be required to
resolve the operator-operand
associations whenever an expression has a nonassociative operator to the left of an operator of the same precedence.
5. CONSTANTS, VARIABLES, AND SCOPES
5A. DECLARATIONS OF CONSTANTS
It shall be possible to associate identifiers with constant values of any type that is not dynamically
allocated. Constants shall include both those whose values are determined at translation time and
those whose value cannot be determined until scope entry time. A translation time error shall be reported
whenever a program attempts to assign to a constant valued identifier.
5B. DECLARATIONS OF VARIABLES
There shall be no default declarations for variables. The type of each variable must be explicitly
specified in programs and shall be determinable at translation time. Variables may be of any time.
5C. SCOPE OF DECLARATIONS
The intended scope of a declaration shall be determinable from the program at
translation time. Scopes may be lexically embedded. Translators shall provide a warning
wherever a local definition masks a more global definition. [Note that a function need not mask a more
global function if they differ in name, number of parameters, or formal parameter types.]
5D. RESTRICTIONS ON VALUES
Procedures, functions, types,
labels, exception situations, and statements shall not be
assignable to variables, computable as values of
expressions, or usable as parameters to
procedures or functions.
5E. INITIAL VALUES
There shall be no default initial values
for variables. The same syntactic form shall not be used both to declare constants and to initialize variables.
[Note that initialization of variables must (except for some global variables) be accomplished during
execution, not translation.]
5F. OPERATIONS ON VARIABLES
Assignment and an implicit value
access operation shall be automatically defined for each
variable.
5G. OTHER DECLARATION
It shall be possible to associate identifiers with specifications of type and representation (including range,
scale, and precision). Such identifiers may be used in declarations of variables, to specify components of
elements of composite types, and in formal parameter specifications.
6. CONTROL STRUCTURES
[ RED Reference RED Rationale ]
6A. BASIC CONTROL FACILITY
The built-in control mechanisms
should be of minimal number and complexity and where possible shall be structured (i.e., shall have one
point of entry and shall exit to a single point).
Each shall provide
a single capability and shall have a distinguishing syntax.
Nesting of control structures shall be allowed. There shall be
no control definition facility. Local scopes shall be allowed
within the bodies of control statements.
6B. SEQUENTIAL CONTROL
There shall be a sequential control mechanism (i.e., a mechanism for sequencing statements).
Explicit statement delimiters shall be required.
[Note the choice between terminators and separators can be left to the user.]
6C. CONDITIONAL CONTROL
There shall be conditional control
structures that permit selection among alternative control
paths. The selected path may depend on the value of a conditional
expression, on a computed choice among labeled alternatives, or
on the true condition in a set of mutually exclusive conditions. The control action
must be specified for all values of the discriminating condition. [Note that only
one branch will be compiled when the selected case for a conditional statement is determinable at translation
time.]
6D. SHORT CIRCUIT EVALUATION
There shall be forms for short circuit conjunction and disjunction of Boolean expression in
conditional and iterative control structures.
6E. ITERATIVE CONTROL
There shall be an iterative control
structure that permits a loop to have several explicit termination conditions
and permits termination anywhere in the loop. Iterative control structures may be entered
only at the head of the loop. [Note that when the number of iterations is zero or one and is determinable
at translation time, the translator can omit any unnecessary object code.]
6F. LOOP CONTROL VARIABLES
Loop control variables, if any, shall be local to the iterative control statement.
Assignment shall not be allowed to control variables from the loop body. It shall be possible to iterate over
sequences of integers and over elements of an enumeration type.
6G. EXPLICIT CONTROL TRANSFER
There shall be an explicit mechanism for
control transfer (i.e., the go to). The go to shall not permit
transfer of control out of
declarations (including functions, procedures, and encapsulated definitions) or out of parallel control
structures. It shall not permit transfer into narrower access scopes or into control structures (e.g., conditional,
iterative, and parallel control structures). There shall be no control transfer mechanisms in the form of
switches, designational expressions, label variables, label parameters, or alter statements.
7. FUNCTIONS AND PROCEDURES
[ RED Reference RED Rationale ]
7A. FUNCTION AND PROCEDURE DEFINITIONS
Functions (which
return values to expressions) and procedures (which can be
called as statements) shall be definable in programs.
Functions or procedures that differ in the number or types of
their parameters may be denoted by the same identifier or
operator (i.e., overloading shall be permitted). [Note that
redefinition, as opposed to overloading, of an existing
function or procedure is often error prone.]
7B. RECURSION
It shall be possible to call functions and
procedures recursively.
7C. SCOPE RULES
A reference to an identifier that is not
declared in the most local scope shall refer to a program
element that is lexically global, rather than to one that is
global through the dynamic calling structure.
7.1 FUNCTIONS
7.1.D.(7D.) FUNCTION DECLARATIONS
The result type for each
function must be explicitly specified in the function declaration and shall be
determinable at translation time. A function of two arguments may be specified as associative in its
declaration. [Note that the latter requirement reduces the need for explicit parentheses.]
7.1.E.(7E.) RESTRICTIONS ON FUNCTIONS
A function may only have input parameters and may not be called in a scope that
contains variables that are referenced or assigned directly or indirectly within the body of the function.
[Note that this requirement guarantees that parameters to functions can be implemented safely with either
value or reference passing.]
7.2 PARAMETERS
7.2.F. (7F.) FORMAL PARAMETER CLASSES
There shall be three classes of
formal data parameters:
- input parameters, which act as
constants that are initialized to the value of corresponding
actual parameters at the time of call,
- input-output
parameters, which enable access and assignment to the
corresponding actual parameters, and
- output parameters, which act as local variables whose
values are transferred to the corresponding actual parameter
only at the time of normal exit. In the latter two cases the corresponding actual parameter
must be a variable or an assignable component of a composite type.
7.2.G. (7G.) PARAMETER SPECIFICATIONS
The type of each formal
parameter must be explicitly specified in programs and shall be
determinable at translation time. Parameters may be of any
type. Range, precision, and scale specifications shall be required for each formal
parameter of appropriate numeric types. A translation time error shall be reported
wherever corresponding formal and actual parameters are of different types and wherever
a program attempts to use a constant or an expression where a variable is requited.
7.2.H. (7H.) FORMAL ARRAY PARAMETERS
The number of dimensions for
formal array parameters must be specified in programs and shall
be determinable at translation time. Determination of the
subscript range for formal array parameters may be delayed
until execution and may vary from call to call. Subscript
ranges shall be accessible within function and procedure bodies
without being passed as an explicit argument.
7I. RESTRICTIONS TO PREVENT ALIASING
Aliasing (i.e., multiple access paths to the
same variable from a given scope) shall not be permitted.
In particular, a variable may not be used as two
output arguments in the same call to a procedure, and a nonlocal variable that is
accessed or assigned within a procedure body may not be used as an output argument
to that procedure.
8. INPUT-OUTPUT FACILITIES
[ RED Reference: Low-Level High-Level
RED Rationale: Low-Level High-Level ]
8A. LOW LEVEL INPUT-OUTPUT OPERATIONS
There shall be a set of built-in low level
input-output operations that act on physical files (e.g., input-output channels and
peripheral devices). The low level operations shall be chosen to insure that all application level
input-output operations can be defined within the language. They shall include operations to send
control information, to receive control information, to begin transfer of data in
either direction, and to wait for completion of a data transfer.
8B. APPLICATION LEVEL INPUT-OUTPUT OPERATIONS
There shall be standard library definitions for application level input-output to logical files. These shall include
operations for crating, deleting, opening, closing, reading, writing, and positioning logical files.
The meaning of such operations shall depend on the general characteristics of the files or devices (e.g., on whether
they are sequentially or randomly accessed), but shall not be dependent on a specific device.
8C. INPUT RESTRICTIONS
Input shall be restricted
to files whose record representation is known to the
translator (i.e., to files that are created and written entirely
within the program or to files whose data representation is explicitly
specified in the program).
8D. OPERATING SYSTEM INDEPENDENCE
The language shall not
require the presence of an operating system. The form and meaning
of built-in and library definitions shall not be dependent on the operating system, if present.
[Note that functions and operators of the language can be implemented as operating system calls
where the operating system is compatible with the function or operator definition.]
8E. CONFIGURATION CONTROL
There shall be a few low level facilities that permit programs (usually library routines) to interrogate and
control the status of physical resources (e.g., memory or processors) that are managed (e.g., allocated or scheduled) by
built-in features of the language. In particular it shall be possible to dynamically reassign the
association between physical and logical devices, to control program overlays, and to prevent allocation and
scheduling of faulty resources.
9. PARALLEL PROCESSING
[ RED Reference RED Rationale ]
9A. PARALLEL CONTROL STRUCTURES
There shall be a control structure for parallel processing. It shall permit a fixed number
(i.e., determinable at translation time) of control paths to operate in parallel and to
rejoin at a single point. There shall be an operation that is executable on any path of a parallel control structure
and that causes immediate termination of the other paths (i.e., causes the other paths to move to the rejoin point).
9B. PARALLEL PATH IMPLEMENTATION
The parallel processing
facility shall be designed to minimize execution cost. In particular, parallel control
paths shall be implementable with multiprocessors or with interleaved execution on a single processor.
9C. MUTUAL EXCLUSION
Thee shall be a mechanism for mutual exclusion among parallel processes. During specified portions of its execution,
a parallel path shall be able to wait for and gain exclusive use of certain program declared
objects and to release those objects. [Note that special asynchronous hardware and software interrupt
facilities are not necessary in the language; interrupts can be treated as objects that are released
upon occurrence of the interrupt.]
9D. REAL TIME CONSTRAINTS AND SCHEDULING
Constraints on the real (i.e., elapsed) time for execution of portions of control paths shall be specifiable in programs.
Translators shall give warning if there is risk that time constraint will not be met. It shall also
be possible to specify which paths are to be given preference in execution (in case the number of
actual paths exceeds the number of available processors or the processors execute at different speeds). [Note:
Such specifications provide a means to document the real time constraints of the applications, but do not specify a
specific execution order among parallel paths and do not
provide a safe means for mutual exclusion.]
9E. REAL TIME CLOCK
There shall be an accessible real time
clock. It shall be possible to delay on any control path
for specified real time intervals. Such specifications shall be interpreted as the minimum time before continuing
execution on that control path.
9F. SIMULATED TIME CLOCK
There shall be an accessible simulated time clock. It shall be possible to delay any control path for a specified
simulated time interval.
10. EXCEPTION HANDLING
[ RED Reference RED Rationale ]
10A. EXCEPTION HANDLING FACILITY
There shall be an exception
handling mechanism for responding to unplanned error situations
detected during program execution. The
exception situations shall include errors detected by hardware,
software errors detected during execution, error situations in
built-in operations, and attempts to execute portions of programs that are not present in
main memory. Exceptions should add to the
execution time of programs only if they are invoked.
10B. SOFTWARE ERROR SITUATIONS
The software errors detectable during execution
shall include exceeding the specified range of an array
subscript, exceeding the specified range of a variable,
exceeding the implemented range of a variable, attempting to
access an uninitialized variable, attempting to access an
uninitialized variable, and failing to satisfy a program specified assertion.
[Note that many range checks can be done during translation thereby reducing execution costs.]
10C. INVOKING EXCEPTIONS
During any function or procedure execution it shall be possible to invoke an
exception situation in the calling statement. This
exception shall cause termination of the routine and an immediate transfer of control in the caller.
Such exceptions must be specified in the definition of the function or procedure.
Exceptions that can be invoked by built-in operations shall be given in the language definition.
10D. PROCESSING EXCEPTIONS
There shall be a control structure
for discriminating among the exceptions that can occur in a
specified portion of a program. Exceptions that are not processed at a given function or procedure level shall
cause termination of the function or procedure and shall invoke an exception in its caller.
Exceptions that cause exit from parallel control structures shall terminate all paths of the parallel control structures.
10E. ORDER OF EXCEPTIONS
The order in which exceptions in
different parts of an expression are detected shall not be
guaranteed by the language or by the translator.
10F. ASSERTIONS
It shall be possible to include assertions
in programs. If an assertion is false when encountered during
execution, it shall invoke an exception.
[Note that assertions can also be used to aid optimization and
maintenance.]
10G. SUPPRESSING EXCEPTIONS
It shall be possible to suppress individually the detection of
exceptions for software error situations. Should such a situation occur
when its detection is suppressed, the consequences will be unpredictable.
11. SPECIFICATIONS OF OBJECT REPRESENTATION
[ RED Reference RED Rationale ]
11A. DATA REPRESENTATION
The language shall permit but not
require programs to specify a single physical representation
of data. These specifications shall be
distinct from the logical descriptions. Specifications for the order of fields, the width of fields,
the presence of "don't care" fields, the positions of word boundaries,
and the object machine representation of atomic data shall be allowed.
If object representations are not specified, they shall be determined by the translator.
11B. MULTIPLE REPRESENTATIONS
It shall be possible in programs to define more than one physical representation (e.g., packed and unpacked) for elements of
a given type, and to associate a specific representation with each
variable of that type. [Note that changes of representation can be accomplished through assignment.]
11C. MACHINE CONFIGURATION CONSTANTS
The language shall require the declaration of certain global constants of the object machine configuration. These shall include
constants that specify the machine model, the memory size, special hardware options,
the operating system if present, and peripheral equipment. Such constants shall be used to determine the object code to
be generated by the translator and may also be used by the program like other constants. [Note that the user can define constants
and use them as switches to control user defined compilation options.]
11D. CONFIGURATION DEPENDENT SPECIFICATIONS
It shall be possible to use machine dependent facilities in programs. Portions of programs that depend on the
characteristics of the object machine (e.g., on the machine model, special hardware options,
device configuration, or operating system) shall be permitted only within branches of conditional control structures that
discriminate on the object machine configuration.
11E. CODE INSERTIONS
For some object machines it shall be possible to write programs that include encapsulated code
written in machine language or in other established programming languages. Such
facilities shall be modest and shall attempt to maximize safety. The language should be designed to minimize
the need for code insertions.
11F. OPTIMIZATION SPECIFICATIONS
It shall be possible in programs to specify the optimization criteria to be used. It shall be possible to specify
whether minimum translation costs or minimum execution costs are more
important. In the latter case the user may also specify
whether execution time or memory space is to be given preference. The meanings of program constructs
(other than execution time and space) shall not depend on the optimizations that are applied.
12. LIBRARY, SEPARATE COMPILATION, AND GENERIC DEFINITIONS
[ RED Reference RED Rationale ]
12A. LIBRARY ENTRIES
The language shall support the use of an external library of definitions and separately compiled segments. Library entries shall
include type definitions, input-output packages, common pools of shared declarations, and application-oriented
software packages. The library shall be structured to allow entries to be associated with a particular
application, project or user.
12B. SEPARATELY COMPILED SEGMENTS
The language shall support the assembly of separately compiled program segments into an operational program.
It shall allow definitions made in one separately compiled segment to be used in another,
and shall require that such definitions and declarations be explicitly
exported from the defining segment and be explicitly, but not necessarily individually, imported to the using segment.
Type constraints and other program and language imposed restrictions shall be enforced across such interfaces.
12C. RESTRICTIONS ON SEPARATE COMPILATION
Separate compilation shall not change the meaning of a program. Translators shall be responsible fro the integrity of object
code in affected segments when any segment is modified, and shall insure that shared definitions have
compatible representations in all segments. [Note: This
suggests that a segment cannot be compiled until all segments from which it imports definitions and
declarations, are defined.]
12D. GENERIC DEFINITIONS
It shall be possible to define functions, procedures, and types with parameters
that are instantiated during translation at each call. Such parameters may be any defined identifier (including those for variables, functions,
or types), an expression, ro a statement. These parameters,
like all other parameters, shall be evaluated in the context of the call. [Note that generic definitions
generally cannot be separately compiled, but where generic definitions are
implemented as closed routines, several instantiations can often share the same object code.]
13. SUPPORT FOR THE LANGUAGE
13A. DEFINING DOCUMENTS
The language shall have a complete
and unambiguous definition. It should be possible to
predict the complete action of any syntactically correct
program from the language definition. The language
documentation shall include the syntax, semantics, and
appropriate examples of each feature including those for standard library definitions.
The defining documentation might point out the relative efficiency of alternative constructs.
13B. STANDARDS
There will be a standard definition Of the
language. Procedures will be established for standards control
and for certification that implementations meet the standard.
13C. SUBSET AND SUPERSET IMPLEMENTATIONS
Translators shall
implement the standard definition. There shall be no subset or superset implementations. Every
feature that is available to the user shall be defined in the
standard, in an accessible library, or in the source program.
13D. TRANSLATOR DIAGNOSTICS
Translators shall be responsible
for reporting errors that are detectable at translation time and
for optimizing object code. Translators shall do full syntax and
type checking, shall check that all language imposed
restrictions are met, and should provide warnings of unusually expensive constructs.
A representative set of translation time diagnostic and warning messages shall be included in the language definition.
13E. TRANSLATOR CHARACTERISTICS
Translators for the language
shall be written in the language and shall be able to produce
code for a variety of object machines.
Where practical, the machine independent
parts of translators should be separate from the code generators.
Self hosting of translators is desirable, but is not required
(i.e., the translator need not be able to run on all the object machines).
The internal characteristics
of the translator (i.e., the translation method) shall not be
dictated by the language definition or standards.
13F. RESTRICTIONS ON TRANSLATORS
Translators shall fail to
compile correct programs only when the program
exceeds the resources or capabilities of the intended object machine or when
the program requires more resources during the translation
than are unavailable on the host machine. Translators shall report
an error when a program requires memory, devices, or special hardware
that are unavailable in the object machine. Neither
the language nor its translators shall impose
arbitrary restrictions on language features. That is, they shall not
impose restrictions on the number of array dimensions, on the size of data structures,
on the size of set types, on the number of identifiers, on the length of identifiers,
or on the number of nested parentheses levels unless such restrictions are dictated by the
limitations of the host or object machine and are documented in user accessible manuals.
13G. SOFTWARE TOOLS AND APPLICATION PACKAGES
The language
shall be designed to work in conjunction with a variety of
useful software tools and application support packages. These
will be developed as early as possible and will include
editors, interpreters, diagnostic aids, program analyzers,
documentation aids, testing aids, software maintenance tools,
optimizers, and application libraries. There will be a
consistent user interface for these tools. Where practical
software tools and aids will be written in the language.
Support for the design, implementation, distribution, and
maintenance of translators, software tools and aids, and
application libraries will be provided independently of the
individual projects that use them.
****************
For a more detailed discussion of the DoD common language effort, the requirements background, and the relation
of programming languages to the DoD software problem see:
- Department of Defense Requirements for High Order Computer Programming Languages, "TINMAN", June 1976, or
- IDA Paper P-1191, "A Common Programming Language for the Department of Defense -- Background and Technical
Requirements", David A. Fisher, June 1976.
Both of these documents have been widely distributed and both contain the December 1975 set of requirements.
