Go to the first, previous, next, last section, table of contents.


General

  1. Ada is a programming language designed to support the construction of long-lived, highly reliable software systems. The language includes facilities to define packages of related types, objects, and operations. The packages may be parameterized and the types may be extended to support the construction of libraries of reusable, adaptable software components. The operations may be implemented as subprograms using conventional sequential control structures, or as entries that include synchronization of concurrent threads of control as part of their invocation. The language treats modularity in the physical sense as well, with a facility to support separate compilation.
  2. The language includes a complete facility for the support of real-time, concurrent programming. Errors can be signaled as exceptions and handled explicitly. The language also covers systems programming; this requires precise control over the representation of data and access to system-dependent properties. Finally, a predefined environment of standard packages is provided, including facilities for, among others, input-output, string manipulation, numeric elementary functions, and random number generation.

Scope

  1. This International Standard specifies the form and meaning of programs written in Ada. Its purpose is to promote the portability of Ada programs to a variety of data processing systems.

Extent

  1. This International Standard specifies:
    1. The form of a program written in Ada;
    2. The effect of translating and executing such a program;
    3. The manner in which program units may be combined to form Ada programs;
    4. The language-defined library units that a conforming implementation is required to supply;
    5. The permissible variations within the standard, and the manner in which they are to be documented;
    6. Those violations of the standard that a conforming implementation is required to detect, and the effect of attempting to translate or execute a program containing such violations;
    7. Those violations of the standard that a conforming implementation is not required to detect.
  1. This International Standard does not specify:
    1. The means whereby a program written in Ada is transformed into object code executable by a processor;
    2. The means whereby translation or execution of programs is invoked and the executing units are controlled;
    3. The size or speed of the object code, or the relative execution speed of different language constructs; The form or contents of any listings produced by implementations; in particular, the form or contents of error or warning messages;
    4. The effect of unspecified execution.
    5. The size of a program or program unit that will exceed the capacity of a particular conforming implementation.

Structure

  1. This International Standard contains thirteen sections, fourteen annexes, and an index.
  2. The core of the Ada language consists of:
    1. Sections 1 through 13
    2. Annex A, "Predefined Language Environment"
    3. Annex B, "Interface to Other Languages"
    4. Annex J, "Obsolescent Features"
  1. The following Specialized Needs Annexes define features that are needed by certain application areas:
    1. Annex C, "Systems Programming"
    2. Annex D, "Real-Time Systems"
    3. Annex E, "Distributed Systems"
    4. Annex F, "Information Systems"
    5. Annex G, "Numerics"
    6. Annex H, "Safety and Security"
  1. The core language and the Specialized Needs Annexes are normative, except that the material in each of the items listed below is informative:
    1. Text under a NOTES or Examples heading.
    2. Each clause or subclause whose title starts with the word "Example" or "Examples".
  1. All implementations shall conform to the core language. In addition, an implementation may conform separately to one or more Specialized Needs Annexes.
  2. The following Annexes are informative:
    1. Annex K, "Language-Defined Attributes"
    2. Annex L, "Language-Defined Pragmas"
    3. Annex M, "Implementation-Defined Characteristics"
    4. Annex N, "Glossary"
    5. Annex P, "Syntax Summary"
  1. Each section is divided into clauses and subclauses that have a common structure. Each section, clause, and subclause first introduces its subject. After the introductory text, text is labeled with the following headings: Syntax
  2. Syntax rules (indented). Name Resolution Rules
  3. Compile-time rules that are used in name resolution, including overload resolution. Legality Rules
  4. Rules that are enforced at compile time. A construct is legal if it obeys all of the Legality Rules. Static Semantics
  5. A definition of the compile-time effect of each construct. Post-Compilation Rules
  6. Rules that are enforced before running a partition. A partition is legal if its compilation units are legal and it obeys all of the Post-Compilation Rules. Dynamic Semantics
  7. A definition of the run-time effect of each construct. Bounded (Run-Time) Errors
  8. Situations that result in bounded (run-time) errors, see section Classification of Errors. Erroneous Execution
  9. Situations that result in erroneous execution, see section Classification of Errors. Implementation Requirements
  10. Additional requirements for conforming implementations. Documentation Requirements
  11. Documentation requirements for conforming implementations. Metrics
  12. Metrics that are specified for the time/space properties of the execution of certain language constructs. Implementation Permissions
  13. Additional permissions given to the implementer. Implementation Advice
  14. Optional advice given to the implementer. The word "should" is used to indicate that the advice is a recommendation, not a requirement. It is implementation defined whether or not a given recommendation is obeyed. NOTES
  15. (1) Notes emphasize consequences of the rules described in the (sub)clause or elsewhere. This material is informative. Examples
  16. Examples illustrate the possible forms of the constructs described. This material is informative.

Conformity of an Implementation with the Standard

Implementation Requirements

  1. A conforming implementation shall:
    1. Translate and correctly execute legal programs written in Ada, provided that they are not so large as to exceed the capacity of the implementation;
    2. Identify all programs or program units that are so large as to exceed the capacity of the implementation (or raise an appropriate exception at run time);
    3. Identify all programs or program units that contain errors whose detection is required by this International Standard;
    4. Supply all language-defined library units required by this International Standard;
    5. Contain no variations except those explicitly permitted by this International Standard, or those that are impossible or impractical to avoid given the implementation's execution environment;
    6. Specify all such variations in the manner prescribed by this International Standard.
  1. The external effect of the execution of an Ada program is defined in terms of its interactions with its external environment. The following are defined as external interactions:
    1. Any interaction with an external file, see section External Files and File Objects,
    2. The execution of certain code_statements, see section Machine Code Insertions, which code_statements cause external interactions is implementation defined.
    3. Any call on an imported subprogram, see section Interface to Other Languages (normative), including any parameters passed to it;
    4. Any result returned or exception propagated from a main subprogram, See section Program Execution, or an exported subprogram, see section Interface to Other Languages (normative), to an external caller;
    5. Any read or update of an atomic or volatile object, see section Shared Variable Control,
    6. The values of imported and exported objects, see section Interface to Other Languages (normative), at the time of any other interaction with the external environment.
  1. A conforming implementation of this International Standard shall produce for the execution of a given Ada program a set of interactions with the external environment whose order and timing are consistent with the definitions and requirements of this International Standard for the semantics of the given program.
  2. An implementation that conforms to this Standard shall support each capability required by the core language as specified. In addition, an implementation that conforms to this Standard may conform to one or more Specialized Needs Annexes (or to none). Conformance to a Specialized Needs Annex means that each capability required by the Annex is provided as specified.
  3. An implementation conforming to this International Standard may provide additional attributes, library units, and pragmas. However, it shall not provide any attribute, library unit, or pragma having the same name as an attribute, library unit, or pragma (respectively) specified in a Specialized Needs Annex unless the provided construct is either as specified in the Specialized Needs Annex or is more limited in capability than that required by the Annex. A program that attempts to use an unsupported capability of an Annex shall either be identified by the implementation before run time or shall raise an exception at run time. Documentation Requirements
  4. Certain aspects of the semantics are defined to be either implementation defined or unspecified. In such cases, the set of possible effects is specified, and the implementation may choose any effect in the set. Implementations shall document their behavior in implementation-defined situations, but documentation is not required for unspecified situations. The implementation-defined characteristics are summarized in Annex M.
  5. The implementation may choose to document implementation-defined behavior either by documenting what happens in general, or by providing some mechanism for the user to determine what happens in a particular case. Implementation Advice
  6. If an implementation detects the use of an unsupported Specialized Needs Annex feature at run time, it should raise Program_Error if feasible.
  7. If an implementation wishes to provide implementation-defined extensions to the functionality of a language-defined library unit, it should normally do so by adding children to the library unit. NOTES
  8. (2) The above requirements imply that an implementation conforming to this Standard may support some of the capabilities required by a Specialized Needs Annex without supporting all required capabilities.

Method of Description and Syntax Notation

  1. The form of an Ada program is described by means of a context-free syntax together with context-dependent requirements expressed by narrative rules.
  2. The meaning of Ada programs is described by means of narrative rules defining both the effects of each construct and the composition rules for constructs.
  3. The context-free syntax of the language is described using a simple variant of Backus-Naur Form. In particular:
    1. Lower case words in a sans-serif font, some containing embedded underlines, are used to denote syntactic categories, for example:
    2. case_statement
      
    3. Boldface words are used to denote reserved words, for example:
    4. array
      
    5. Square brackets enclose optional items. Thus the two following rules are equivalent.
    6. return_statement ::= return [expression];
      return_statement ::= return; | return expression;
      
    7. Curly brackets enclose a repeated item. The item may appear zero or more times; the repetitions occur from left to right as with an equivalent left-recursive rule. Thus the two following rules are equivalent.
    8. term ::= factor {multiplying_operator factor}
      term ::= factor | term multiplying_operator factor
      
    9. A vertical line separates alternative items unless it occurs immediately after an opening curly bracket, in which case it stands for itself:
    10. constraint ::= scalar_constraint | composite_constraint
      discrete_choice_list ::= discrete_choice {| discrete_choice}
      
    11. If the name of any syntactic category starts with an italicized part, it is equivalent to the category name without the italicized part. The italicized part is intended to convey some semantic information. For example subtype_name and task_name are both equivalent to name alone.
  1. A syntactic category is a nonterminal in the grammar defined in BNF under "Syntax." Names of syntactic categories are set in a different font, like_this.
  2. A construct is a piece of text (explicit or implicit) that is an instance of a syntactic category defined under "Syntax."
  3. A constituent of a construct is the construct itself, or any construct appearing within it.
  4. Whenever the run-time semantics defines certain actions to happen in an arbitrary order, this means that the implementation shall arrange for these actions to occur in a way that is equivalent to some sequential order, following the rules that result from that sequential order. When evaluations are defined to happen in an arbitrary order, with conversion of the results to some subtypes, or with some run-time checks, the evaluations, conversions, and checks may be arbitrarily interspersed, so long as each expression is evaluated before converting or checking its value. Note that the effect of a program can depend on the order chosen by the implementation. This can happen, for example, if two actual parameters of a given call have side effects. NOTES
  5. (3) The syntax rules describing structured constructs are presented in a form that corresponds to the recommended paragraphing. For example, an if_statement is defined as:
  6. if_statement ::=
       if condition then
          sequence_of_statements
       {elsif condition then
          sequence_of_statements}
       [else
          sequence_of_statements]
       end if;
    
  7. (4) The line breaks and indentation in the syntax rules indicate the recommended line breaks and indentation in the corresponding constructs. The preferred places for other line breaks are after semicolons.

Classification of Errors

Implementation Requirements

  1. The language definition classifies errors into several different categories:
    1. Errors that are required to be detected prior to run time by every Ada implementation;
      1. These errors correspond to any violation of a rule given in this International Standard, other than those listed below. In particular, violation of any rule that uses the terms shall, allowed, permitted, legal, or illegal belongs to this category. Any program that contains such an error is not a legal Ada program; on the other hand, the fact that a program is legal does not mean, per se, that the program is free from other forms of error.
      2. The rules are further classified as either compile time rules, or post compilation rules, depending on whether a violation has to be detected at the time a compilation unit is submitted to the compiler, or may be postponed until the time a compilation unit is incorporated into a partition of a program.
    1. Errors that are required to be detected at run time by the execution of an Ada program;
      1. The corresponding error situations are associated with the names of the predefined exceptions. Every Ada compiler is required to generate code that raises the corresponding exception if such an error situation arises during program execution. If such an error situation is certain to arise in every execution of a construct, then an implementation is allowed (although not required) to report this fact at compilation time.
    1. Bounded errors;
      1. The language rules define certain kinds of errors that need not be detected either prior to or during run time, but if not detected, the range of possible effects shall be bounded. The errors of this category are called bounded errors. The possible effects of a given bounded error are specified for each such error, but in any case one possible effect of a bounded error is the raising of the exception Program_Error.
    1. Erroneous execution.
      1. In addition to bounded errors, the language rules define certain kinds of errors as leading to erroneous execution. Like bounded errors, the implementation need not detect such errors either prior to or during run time. Unlike bounded errors, there is no language-specified bound on the possible effect of erroneous execution; the effect is in general not predictable.

Implementation Permissions

  1. An implementation may provide nonstandard modes of operation. Typically these modes would be selected by a pragma or by a command line switch when the compiler is invoked. When operating in a nonstandard mode, the implementation may reject compilation_units that do not conform to additional requirements associated with the mode, such as an excessive number of warnings or violation of coding style guidelines. Similarly, in a nonstandard mode, the implementation may apply special optimizations or alternative algorithms that are only meaningful for programs that satisfy certain criteria specified by the implementation. In any case, an implementation shall support a standard mode that conforms to the requirements of this International Standard; in particular, in the standard mode, all legal compilation_units shall be accepted. Implementation Advice
  2. If an implementation detects a bounded error or erroneous execution, it should raise Program_Error.

Normative References

  1. The following standards contain provisions which, through reference in this text, constitute provisions of this International Standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this International Standard are encouraged to investigate the possibility of applying the most recent editions of the standards indicated below. Members of IEC and ISO maintain registers of currently valid International Standards.
  2. ISO/IEC 646:1991, Information technology -- ISO 7-bit coded character set for information interchange.
  3. ISO/IEC 1539:1991, Information technology -- Programming languages -- FORTRAN.
  4. ISO 1989:1985, Programming languages -- COBOL.
  5. ISO/IEC 6429:1992, Information technology -- Control functions for coded graphic character sets.
  6. ISO/IEC 8859-1:1987, Information processing -- 8-bit single-byte coded character sets -- Part 1: Latin alphabet No. 1.
  7. ISO/IEC 9899:1990, Programming languages -- C.
  8. ISO/IEC 10646-1:1993, Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane.

Definitions

  1. Terms are defined throughout this International Standard, indicated by italic type. Terms explicitly defined in this International Standard are not to be presumed to refer implicitly to similar terms defined elsewhere. Terms not defined in this International Standard are to be interpreted according to the Webster's Third New International Dictionary of the English Language. Informal descriptions of some terms are also given in Annex N, "Glossary".


Go to the first, previous, next, last section, table of contents.