===================================================================== INTERNATIONAL STANDARD ISO/IEC 8652:2012(E) with Cor 1:2016 ===================================================================== Information technology - Programming Languages - Ada 1 General 1.1 Scope 1/3 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 computing systems. 2/3 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. Ada supports object-oriented programming by providing classes and interfaces, inheritance, polymorphism of variables and methods, and generic units. The language treats modularity in the physical sense as well, with a facility to support separate compilation. 3/4 The language provides rich support for real-time, concurrent programming, and includes facilities for multicore and multiprocessor 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, random number generation, and definition and use of containers. 1.1.1 Extent 1 This International Standard specifies: 2 * The form of a program written in Ada; 3 * The effect of translating and executing such a program; 4 * The manner in which program units may be combined to form Ada programs; 5 * The language-defined library units that a conforming implementation is required to supply; 6 * The permissible variations within the standard, and the manner in which they are to be documented; 7 * 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; 8 * Those violations of the standard that a conforming implementation is not required to detect. 9 This International Standard does not specify: 10 * The means whereby a program written in Ada is transformed into object code executable by a processor; 11 * The means whereby translation or execution of programs is invoked and the executing units are controlled; 12 * The size or speed of the object code, or the relative execution speed of different language constructs; 13 * The form or contents of any listings produced by implementations; in particular, the form or contents of error or warning messages; 14 * The effect of unspecified execution. 15 * The size of a program or program unit that will exceed the capacity of a particular conforming implementation. 1.1.2 Structure 1/3 This International Standard contains thirteen clauses, fifteen annexes, and an index. 2 The core of the Ada language consists of: 3/3 * Clauses 1 through 13 4 * Annex A, "Predefined Language Environment" 5 * Annex B, "Interface to Other Languages" 6 * Annex J, "Obsolescent Features" 7 The following Specialized Needs Annexes define features that are needed by certain application areas: 8 * Annex C, "Systems Programming" 9 * Annex D, "Real-Time Systems" 10 * Annex E, "Distributed Systems" 11 * Annex F, "Information Systems" 12 * Annex G, "Numerics" 13 * Annex H, "High Integrity Systems" 14 The core language and the Specialized Needs Annexes are normative, except that the material in each of the items listed below is informative: 15 * Text under a NOTES or Examples heading. 16/3 * Each subclause whose title starts with the word "Example" or " Examples". 17 All implementations shall conform to the core language. In addition, an implementation may conform separately to one or more Specialized Needs Annexes. 18 The following Annexes are informative: 19 * Annex K, "Language-Defined Aspects and Attributes" 20 * Annex L, "Language-Defined Pragmas" 21/3 * Annex M, "Summary of Documentation Requirements" 22 * Annex N, "Glossary" 23 * Annex P, "Syntax Summary" 23.1/3 * Annex Q, "Language-Defined Entities" 24/4 Each clause is divided into subclauses that have a common structure. Each clause and subclause first introduces its subject. After the introductory text, text is labeled with the following headings: Syntax 25 Syntax rules (indented). Name Resolution Rules 26/3 Compile-time rules that are used in name resolution, including overload resolution. Legality Rules 27 Rules that are enforced at compile time. A construct is legal if it obeys all of the Legality Rules. Static Semantics 28 A definition of the compile-time effect of each construct. Post-Compilation Rules 29 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 30 A definition of the run-time effect of each construct. Bounded (Run-Time) Errors 31 Situations that result in bounded (run-time) errors (see 1.1.5). Erroneous Execution 32 Situations that result in erroneous execution (see 1.1.5). Implementation Requirements 33 Additional requirements for conforming implementations. Documentation Requirements 34 Documentation requirements for conforming implementations. Metrics 35 Metrics that are specified for the time/space properties of the execution of certain language constructs. Implementation Permissions 36 Additional permissions given to the implementer. Implementation Advice 37 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 38 1 Notes emphasize consequences of the rules described in the (sub)clause or elsewhere. This material is informative. Examples 39 Examples illustrate the possible forms of the constructs described. This material is informative. 1.1.3 Conformity of an Implementation with the Standard Implementation Requirements 1 A conforming implementation shall: 2 * Translate and correctly execute legal programs written in Ada, provided that they are not so large as to exceed the capacity of the implementation; 3 * 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); 4 * Identify all programs or program units that contain errors whose detection is required by this International Standard; 5 * Supply all language-defined library units required by this International Standard; 6 * 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; 7 * Specify all such variations in the manner prescribed by this International Standard. 8 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: 9 * Any interaction with an external file (see A.7); 10 * The execution of certain code_statements (see 13.8); which code_statements cause external interactions is implementation defined. 11 * Any call on an imported subprogram (see Annex B), including any parameters passed to it; 12 * Any result returned or exception propagated from a main subprogram (see 10.2) or an exported subprogram (see Annex B) to an external caller; 13 * Any read or update of an atomic or volatile object (see C.6); 14 * The values of imported and exported objects (see Annex B) at the time of any other interaction with the external environment. 15 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. 16 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. 17/3 An implementation conforming to this International Standard may provide additional aspects, attributes, library units, and pragmas. However, it shall not provide any aspect, attribute, library unit, or pragma having the same name as an aspect, 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 18 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 M.2. 19 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 20 If an implementation detects the use of an unsupported Specialized Needs Annex feature at run time, it should raise Program_Error if feasible. 21 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 22 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. 1.1.4 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: 4 * Lower case words in a sans-serif font, some containing embedded underlines, are used to denote syntactic categories, for example: 5 case_statement 6 * Boldface words are used to denote reserved words, for example: 7 array 8 * Square brackets enclose optional items. Thus the two following rules are equivalent. 9/2 simple_return_statement ::= return [expression]; simple_return_statement ::= return; | return expression; 10 * 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. 11 term ::= factor {multiplying_operator factor} term ::= factor | term multiplying_operator factor 12 * A vertical line separates alternative items unless it occurs immediately after an opening curly bracket, in which case it stands for itself: 13 constraint ::= scalar_constraint | composite_constraint discrete_choice_list ::= discrete_choice {| discrete_choice} 14 * 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. 14.1/3 The delimiters, compound delimiters, reserved words, and numeric_literals are exclusively made of the characters whose code point is between 16#20# and 16#7E#, inclusively. The special characters for which names are defined in this International Standard (see 2.1) belong to the same range. For example, the character E in the definition of exponent is the character whose name is "LATIN CAPITAL LETTER E", not "GREEK CAPITAL LETTER EPSILON". 14.2/3 When this International Standard mentions the conversion of some character or sequence of characters to upper case, it means the character or sequence of characters obtained by using simple upper case mapping, as defined by documents referenced in the note in Clause 1 of ISO/IEC 10646:2011. 15 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. 16 A construct is a piece of text (explicit or implicit) that is an instance of a syntactic category defined under "Syntax". 17 A constituent of a construct is the construct itself, or any construct appearing within it. 18 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 19 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: 20 if_statement ::= if condition then sequence_of_statements {elsif condition then sequence_of_statements} [else sequence_of_statements] end if; 21 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. 1.1.5 Classification of Errors Implementation Requirements 1 The language definition classifies errors into several different categories: 2 * Errors that are required to be detected prior to run time by every Ada implementation; 3 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. 4 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. 5 * Errors that are required to be detected at run time by the execution of an Ada program; 6 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. 7 * Bounded errors; 8 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. 9 * Erroneous execution. 10 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 11 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 12 If an implementation detects a bounded error or erroneous execution, it should raise Program_Error. 1.2 Normative References 1/3 The following documents, in whole or in part, are normatively referenced in this document and are indispensable for its application. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. 1.1/3 ISO 639-3:2007, Codes for the representation of names of languages - Part 3: Alpha-3 code for comprehensive coverage of languages. 2 ISO/IEC 646:1991, Information technology - ISO 7-bit coded character set for information interchange. 3/2 ISO/IEC 1539-1:2004, Information technology - Programming languages - Fortran - Part 1: Base language. 4/2 ISO/IEC 1989:2002, Information technology - Programming languages - COBOL. 4.1/3 ISO/IEC 3166-1:2006, Codes for the representation of names of countries and their subdivisions - Part 1: Country Codes. 5 ISO/IEC 6429:1992, Information technology - Control functions for coded graphic character sets. 5.1/2 ISO 8601:2004, Data elements and interchange formats - Information interchange - Representation of dates and times. 6/3 ISO/IEC 8859-1:1998, Information technology - 8-bit single-byte coded graphic character sets - Part 1: Latin alphabet No. 1. 7/3 ISO/IEC 9899:2011, Information technology - Programming languages - C. 8/3 ISO/IEC 10646:2011, Information technology - Universal Multiple-Octet Coded Character Set (UCS). 9/3 ISO/IEC 14882:2011, Information technology - Programming languages - C++. 10/2 ISO/IEC TR 19769:2004, Information technology - Programming languages, their environments and system software interfaces - Extensions for the programming language C to support new character data types. 1.3 Terms and Definitions 1/2 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. Mathematical terms not defined in this International Standard are to be interpreted according to the CRC Concise Encyclopedia of Mathematics, Second Edition. Other 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".