INTERNATIONAL STANDARD ISO/IEC 8652:1995(E) INFORMATION TECHNOLOGY -- PROGRAMMING LANGUAGES -- ADA [Revision of first edition (ISO 8652:1987)] ANNOTATED ADA REFERENCE MANUAL Language and Standard Libraries Version 6.0 21 December 1994 Copyright (C) 1992,1993,1994,1995 Intermetrics, Inc. This copyright is assigned to the U.S. Government. All rights reserved. This document may be copied, in whole or in part, in any form or by any means, as is or with alterations, provided that (1) alterations are clearly marked as alterations and (2) this copyright notice is included unmodified in any copy. Compiled copies of standard library units and examples need not contain this copyright notice so long as the notice is included in all copies of source code and documentation. INTERNATIONAL ORGANIZATION FOR STANDARDIZATION INTERNATIONAL ELECTROTECHNICAL COMMISSION Copyright (C) 1992,1993,1994,1995 Intermetrics, Inc. This copyright is assigned to the U.S. Government. All rights reserved. This document may be copied, in whole or in part, in any form or by any means, as is or with alterations, provided that (1) alterations are clearly marked as alterations and (2) this copyright notice is included unmodified in any copy. Compiled copies of standard library units and examples need not contain this copyright notice so long as the notice is included in all copies of source code and documentation. Foreword 1 ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the development of International Standards through technical committees established by the respective organization to deal with particular fields of technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the work. 2 In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1. Draft International Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as an International Standard requires approval by at least 75 % of the national bodies casting a vote. 3 International Standard ISO/IEC 8652 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information Technology. 4 This second edition cancels and replaces the first edition (ISO 8652:1987), of which it constitutes a technical revision. 5 Annexes A to J form an integral part of this International Standard. Annexes K to P are for information only. 5.a Discussion: This document is the Annotated Ada Reference Manual (AARM). It contains the entire text of the Ada 9X standard (ISO/IEC 8652:1995(E)), plus various annotations. It is intended primarily for compiler writers, validation test writers, and other language lawyers. The annotations include detailed rationale for individual rules and explanations of some of the more arcane interactions among the rules. Introduction 1 This is the Annotated Ada Reference Manual. 2 Other available Ada documents include: 3 Rationale for the Ada Programming Language -- 1995 edition, which gives an introduction to the new features of Ada, and explains the rationale behind them. Programmers should read this first. 4 The Ada Reference Manual (RM). This is the International Standard -- ISO/IEC 8652:1995(E). 5 Changes to Ada -- 1987 to 1995. This document lists in detail the changes made to the 1987 edition of the standard. Design Goals 6 Ada was originally designed with three overriding concerns: program reliability and maintenance, programming as a human activity, and efficiency. This revision to the language was designed to provide greater flexibility and extensibility, additional control over storage management and synchroniza- tion, and standardized packages oriented toward supporting important application areas, while at the same time retaining the original emphasis on reliability, maintainability, and efficiency. 7 The need for languages that promote reliability and simplify maintenance is well established. Hence emphasis was placed on program readability over ease of writing. For example, the rules of the language require that program variables be explicitly declared and that their type be specified. Since the type of a variable is invariant, compilers can ensure that operations on variables are compatible with the properties intended for objects of the type. Furthermore, error-prone notations have been avoided, and the syntax of the language avoids the use of encoded forms in favor of more English-like constructs. Finally, the language offers support for separate compilation of program units in a way that facilitates program development and maintenance, and which provides the same degree of checking between units as within a unit. 8 Concern for the human programmer was also stressed during the design. Above all, an attempt was made to keep to a relatively small number of underlying concepts integrated in a consistent and systematic way while continuing to avoid the pitfalls of excessive involution. The design especially aims to provide language constructs that correspond intuitively to the normal expectations of users. 9 Like many other human activities, the development of programs is becoming ever more decentralized and distributed. Consequently, the ability to assemble a program from independently produced software components continues to be a central idea in the design. The concepts of packages, of private types, and of generic units are directly related to this idea, which has ramifications in many other aspects of the language. An allied concern is the maintenance of programs to match changing requirements; type extension and the hierarchical library enable a program to be modified while minimizing disturbance to existing tested and trusted components. 10 No language can avoid the problem of efficiency. Languages that require over-elaborate compilers, or that lead to the inefficient use of storage or execution time, force these inefficiencies on all machines and on all programs. Every construct of the language was examined in the light of present implementation techniques. Any proposed construct whose implementation was unclear or that required excessive machine resources was rejected. Language Summary 11 An Ada program is composed of one or more program units. Program units may be subprograms (which define executable algorithms), packages (which define collections of entities), task units (which define concurrent computations), protected units (which define operations for the coordinated sharing of data between tasks), or generic units (which define parameterized forms of packages and subprograms). Each program unit normally consists of two parts: a specification, containing the information that must be visible to other units, and a body, containing the implementation details, which need not be visible to other units. Most program units can be compiled separately. 12 This distinction of the specification and body, and the ability to compile units separately, allows a program to be designed, written, and tested as a set of largely independent software components. 13 An Ada program will normally make use of a library of program units of general utility. The language provides means whereby individual organizations can construct their own libraries. All libraries are structured in a hierarchical manner; this enables the logical decomposition of a subsystem into individual components. The text of a separately compiled program unit must name the library units it requires. 14 Program Units 15 A subprogram is the basic unit for expressing an algorithm. There are two kinds of subprograms: procedures and functions. A procedure is the means of invoking a series of actions. For example, it may read data, update variables, or produce some output. It may have parameters, to provide a controlled means of passing information between the procedure and the point of call. A function is the means of invoking the computation of a value. It is similar to a procedure, but in addition will return a result. 16 A package is the basic unit for defining a collection of logically related entities. For example, a package can be used to define a set of type declarations and associated operations. Portions of a package can be hidden from the user, thus allowing access only to the logical properties expressed by the package specification. 17 Subprogram and package units may be compiled separately and arranged in hierarchies of parent and child units giving fine control over visibility of the logical properties and their detailed implementation. 18 A task unit is the basic unit for defining a task whose sequence of actions may be executed concurrently with those of other tasks. Such tasks may be implemented on multicomputers, multiprocessors, or with interleaved execution on a single processor. A task unit may define either a single executing task or a task type permitting the creation of any number of similar tasks. 19 A protected unit is the basic unit for defining protected operations for the coordinated use of data shared between tasks. Simple mutual exclusion is provided automatically, and more elaborate sharing protocols can be defined. A protected operation can either be a subprogram or an entry. A protected entry specifies a Boolean expression (an entry barrier) that must be true before the body of the entry is executed. A protected unit may define a single protected object or a protected type permitting the creation of several similar objects. 20 Declarations and Statements 21 The body of a program unit generally contains two parts: a declarative part, which defines the logical entities to be used in the program unit, and a sequence of statements, which defines the execution of the program unit. 22 The declarative part associates names with declared entities. For example, a name may denote a type, a constant, a variable, or an exception. A declarative part also introduces the names and parameters of other nested subprograms, packages, task units, protected units, and generic units to be used in the program unit. 23 The sequence of statements describes a sequence of actions that are to be performed. The statements are executed in succession (unless a transfer of control causes execution to continue from another place). 24 An assignment statement changes the value of a variable. A procedure call invokes execution of a procedure after associating any actual parameters provided at the call with the corresponding formal parameters. 25 Case statements and if statements allow the selection of an enclosed sequence of statements based on the value of an expression or on the value of a condition. 26 The loop statement provides the basic iterative mechanism in the language. A loop statement specifies that a sequence of statements is to be executed repeatedly as directed by an iteration scheme, or until an exit statement is encountered. 27 A block statement comprises a sequence of statements preceded by the declaration of local entities used by the statements. 28 Certain statements are associated with concurrent execution. A delay statement delays the execution of a task for a specified duration or until a specified time. An entry call statement is written as a procedure call statement; it requests an operation on a task or on a protected object, blocking the caller until the operation can be performed. A called task may accept an entry call by executing a corresponding accept statement, which specifies the actions then to be performed as part of the rendezvous with the calling task. An entry call on a protected object is processed when the corresponding entry barrier evaluates to true, whereupon the body of the entry is executed. The requeue statement permits the provision of a service as a number of related activities with preference control. One form of the select statement allows a selective wait for one of several alternative rendezvous. Other forms of the select statement allow conditional or timed entry calls and the asynchronous transfer of control in response to some triggering event. 29 Execution of a program unit may encounter error situations in which normal program execution cannot continue. For example, an arithmetic computation may exceed the maximum allowed value of a number, or an attempt may be made to access an array component by using an incorrect index value. To deal with such error situations, the statements of a program unit can be textually followed by exception handlers that specify the actions to be taken when the error situation arises. Exceptions can be raised explicitly by a raise statement. 30 Data Types 31 Every object in the language has a type, which characterizes a set of values and a set of applicable operations. The main classes of types are elementary types (comprising enumeration, numeric, and access types) and composite types (including array and record types). 32 An enumeration type defines an ordered set of distinct enumeration literals, for example a list of states or an alphabet of characters. The enumeration types Boolean, Character, and Wide_Character are predefined. 33 Numeric types provide a means of performing exact or approximate numerical computations. Exact computations use integer types, which denote sets of consecutive integers. Approximate computations use either fixed point types, with absolute bounds on the error, or floating point types, with relative bounds on the error. The numeric types Integer, Float, and Duration are predefined. 34 Composite types allow definitions of structured objects with related components. The composite types in the language include arrays and records. An array is an object with indexed components of the same type. A record is an object with named components of possibly different types. Task and protected types are also forms of composite types. The array types String and Wide_String are predefined. 35 Record, task, and protected types may have special components called discriminants which parameterize the type. Variant record structures that depend on the values of discriminants can be defined within a record type. 36 Access types allow the construction of linked data structures. A value of an access type represents a reference to an object declared as aliased or to an object created by the evaluation of an allocator. Several variables of an access type may designate the same object, and components of one object may designate the same or other objects. Both the elements in such linked data structures and their relation to other elements can be altered during program execution. Access types also permit references to subprograms to be stored, passed as parameters, and ultimately dereferenced as part of an indirect call. 37 Private types permit restricted views of a type. A private type can be defined in a package so that only the logically necessary properties are made visible to the users of the type. The full structural details that are externally irrelevant are then only available within the package and any child units. 38 From any type a new type may be defined by derivation. A type, together with its derivatives (both direct and indirect) form a derivation class. Class-wide operations may be defined that accept as a parameter an operand of any type in a derivation class. For record and private types, the derivatives may be extensions of the parent type. Types that support these object-oriented capabilities of class-wide operations and type extension must be tagged, so that the specific type of an operand within a derivation class can be identified at run time. When an operation of a tagged type is applied to an operand whose specific type is not known until run time, implicit dispatching is performed based on the tag of the operand. 39 The concept of a type is further refined by the concept of a subtype, whereby a user can constrain the set of allowed values of a type. Subtypes can be used to define subranges of scalar types, arrays with a limited set of index values, and records and private types with particular discriminant values. 40 Other Facilities 41 Representation clauses can be used to specify the mapping between types and features of an underlying machine. For example, the user can specify that objects of a given type must be represented with a given number of bits, or that the components of a record are to be represented using a given storage layout. Other features allow the controlled use of low level, nonportable, or implementation-dependent aspects, including the direct insertion of machine code. 42 The predefined environment of the language provides for input-output and other capabilities (such as string manipulation and random number generation) by means of standard library packages. Input-output is supported for values of user-defined as well as of predefined types. Standard means of representing values in display form are also provided. Other standard library packages are defined in annexes of the standard to support systems with specialized requirements. 43 Finally, the language provides a powerful means of parameterization of program units, called generic program units. The generic parameters can be types and subprograms (as well as objects and packages) and so allow general algorithms and data structures to be defined that are applicable to all types of a given class. Language Changes 44 This International Standard replaces the first edition of 1987. In this edition, the following major language changes have been incorporated: 45 Support for standard 8-bit and 16-bit character sets. See Section 2, 3.5.2, 3.6.3, A.1, A.3, and A.4. 46 Object-oriented programming with run-time polymorphism. See the discussions of classes, derived types, tagged types, record extensions, and private extensions in clauses 3.4, 3.9, and 7.3. See also the new forms of generic formal parameters that are allowed by 12.5.1, ``Formal Private and Derived Types'' and 12.7, ``Formal Packages''. 47 Access types have been extended to allow an access value to designate a subprogram or an object declared by an object declaration (as opposed to just a heap-allocated object). See 3.10. 48 Efficient data-oriented synchronization is provided via protected types. See Section 9. 49 The library units of a library may be organized into a hierarchy of parent and child units. See Section 10. 50 Additional support has been added for interfacing to other languages. See Annex B. 51 The Specialized Needs Annexes have been added to provide specific support for certain application areas: 52 Annex C, ``Systems Programming'' 53 Annex D, ``Real-Time Systems'' 54 Annex E, ``Distributed Systems'' 55 Annex F, ``Information Systems'' 56 Annex G, ``Numerics'' 57 Annex H, ``Safety and Security'' Instructions for Comment Submission 58 {instructions for comment submission} {comments, instructions for submission} Informal comments on this International Standard may be sent via e-mail to ada-comment@sw-eng.falls-church.va.us. If appropriate, the Project Editor will initiate the defect correction procedure. 59 Comments should use the following format: 60 !topic Title summarizing comment !reference RM95-ss.ss(pp) !from Author Name yy-mm-dd !keywords keywords related to topic !discussion text of discussion 61 where ss.ss is the section, clause or subclause number, pp is the paragraph number where applicable, and yy-mm-dd is the date the comment was sent. The date is optional, as is the !keywords line. 62 Multiple comments per e-mail message are acceptable. Please use a descriptive ``Subject'' in your e-mail message. 63 When correcting typographical errors or making minor wording suggestions, please put the correction directly as the topic of the comment; use square brackets [ ] to indicate text to be omitted and curly braces { } to indicate text to be added, and provide enough context to make the nature of the suggestion self-evident or put additional information in the body of the comment, for example: 64 !topic [c]{C}haracter !topic it[']s meaning is not defined 65 Formal requests for interpretations and for reporting defects in this International Standard may be made in accordance with the ISO/IEC JTC1 Directives and the ISO/IEC JTC1/SC22 policy for interpretations. National Bodies may submit a Defect Report to ISO/IEC JTC1/SC22 for resolution under the JTC1 procedures. A response will be provided and, if appropriate, a Technical Corrigendum will be issued in accordance with the procedures. Acknowledgements 66 This International Standard was prepared by the Ada 9X Mapping/Revision Team based at Intermetrics, Inc., which has included: W. Carlson, Program Manager; T. Taft, Technical Director; J. Barnes (consultant); B. Brosgol (consultant); R. Duff (Oak Tree Software); M. Edwards; C. Garrity; R. Hilliard; O. Pazy (consultant); D. Rosenfeld; L. Shafer; W. White; M. Woodger. 67 The following consultants to the Ada 9X Project contributed to the Specialized Needs Annexes: T. Baker (Real-Time/Systems Programming -- SEI, FSU); K. Dritz (Numerics -- Argonne National Laboratory); A. Gargaro (Distributed Systems -- Computer Sciences); J. Goodenough (Real-Time/Systems Programming -- SEI); J. McHugh (Secure Systems -- consultant); B. Wichmann (Safety-Critical Systems -- NPL: UK). 68 This work was regularly reviewed by the Ada 9X Distinguished Reviewers and the members of the Ada 9X Rapporteur Group (XRG): E. Ploedereder, Chairman of DRs and XRG (University of Stuttgart: Germany); B. Bardin (Hughes); J. Barnes (consultant: UK); B. Brett (DEC); B. Brosgol (consultant); R. Brukardt (RR Software); N. Cohen (IBM); R. Dewar (NYU); G. Dismukes (TeleSoft); A. Evans (consultant); A. Gargaro (Computer Sciences); M. Gerhardt (ESL); J. Goodenough (SEI); S. Heilbrunner (University of Salzburg: Austria); P. Hilfinger (UC/Berkeley); B. Kaellberg (CelsiusTech: Sweden); M. Kamrad II (Unisys); J. van Katwijk (Delft University of Technology: The Netherlands); V. Kaufman (Russia); P. Kruchten (Rational); R. Landwehr (CCI: Germany); C. Lester (Portsmouth Polytechnic: UK); L. Mansson (TELIA Research: Sweden); S. Michell (Multiprocessor Toolsmiths: Canada); M. Mills (US Air Force); D. Pogge (US Navy); K. Power (Boeing); O. Roubine (Verdix: France); A. Strohmeier (Swiss Fed Inst of Technology: Switzerland); W. Taylor (consultant: UK); J. Tokar (Tartan); E. Vasilescu (Grumman); J. Vladik (Prospeks s.r.o.: Czech Republic); S. Van Vlierberghe (OFFIS: Belgium). 69 Other valuable feedback influencing the revision process was provided by the Ada 9X Language Precision Team (Odyssey Research Associates), the Ada 9X User/Implementer Teams (AETECH, Tartan, TeleSoft), the Ada 9X Implementation Analysis Team (New York University) and the Ada community-at-large. 70 Special thanks go to R. Mathis, Convenor of ISO/IEC JTC1/SC22 Working Group 9. 71 The Ada 9X Project was sponsored by the Ada Joint Program Office. Christine M. Anderson at the Air Force Phillips Laboratory (Kirtland AFB, NM) was the project manager. Changes 72 The International Standard is the same as this version of the Reference Manual, except: 73 This list of Changes is not included in the International Standard. 74 The ``Acknowledgements'' page is not included in the International Standard. 75 The text in the running headers and footers on each page is slightly different in the International Standard. 76 The title page(s) are different in the International Standard. 77 This document is formatted for 8.5-by-11-inch paper, whereas the International Standard is formatted for A4 paper (210-by-297mm); thus, the page breaks are in different places. ---------------------- INTERNATIONAL STANDARD ---------------------- Information technology -- Programming Languages -- Ada Section 1: 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. 2.a Discussion: This Annotated Ada Reference Manual (AARM) contains the entire text of the Ada Reference Manual (RM9X), plus certain annotations. The annotations give a more in-depth analysis of the language. They describe the reason for each non-obvious rule, and point out interesting ramifications of the rules and interactions among the rules (interesting to language lawyers, that is). Differences between Ada 83 and Ada 9X are listed. (The text you are reading now is an annotation.) 2.b The AARM stresses detailed correctness and uniformity over readability and understandability. We're not trying to make the language ``appear'' simple here; on the contrary, we're trying to expose hidden complexities, so we can more easily detect language bugs. The RM9X, on the other hand, is intended to be a more readable document for programmers. 2.c The annotations in the AARM are as follows: 2.d Text that is logically redundant is shown [in square brackets, like this]. Technically, such text could be written as a Note in the RM9X, since it is really a theorem that can be proven from the non-redundant rules of the language. We use the square brackets instead when it seems to make the RM9X more readable. 2.e The rules of the language (and some AARM-only text) are categorized, and placed under certain sub-headings that indicate the category. For example, the distinction between Name Resolution Rules and Legality Rules is particularly important, as explained in 8.6. 2.f Text under the following sub-headings appears in both documents: 2.g The unlabeled text at the beginning of each clause or subclause, 2.h Syntax, 2.i Name Resolution Rules, 2.j Legality Rules, 2.k Static Semantics, 2.l Post-Compilation Rules, 2.m Dynamic Semantics, 2.n Bounded (Run-Time) Errors, 2.o Erroneous Execution, 2.p Implementation Requirements, 2.q Documentation Requirements, 2.r Metrics, 2.s Implementation Permissions, 2.t Implementation Advice, 2.u NOTES, 2.v Examples. 2.w Text under the following sub-headings does not appear in the RM9X: 2.x Language Design Principles, 2.y Inconsistencies With Ada 83, 2.z Incompatibilities With Ada 83, 2.aa Extensions to Ada 83, 2.bb Wording Changes From Ada 83. 2.cc The AARM also includes the following kinds of annotations. These do not necessarily annotate the immediately preceding rule, although they often do. 2.dd Reason: An explanation of why a certain rule is necessary, or why it is worded in a certain way. 2.ee Ramification: An obscure ramification of the rules that is of interest only to language lawyers. (If a ramification of the rules is of interest to programmers, then it appears under NOTES.) 2.ff Proof: An informal proof explaining how a given Note or [marked-as-redundant] piece of text follows from the other rules of the language. 2.gg Implementation Note: A hint about how to implement a feature, or a particular potential pitfall that an implementer needs to be aware of. 2.hh Discussion: Other annotations not covered by the above. 2.ii To be honest: A rule that is considered logically necessary to the definition of the language, but which is so obscure or pedantic that only a language lawyer would care. These are the only annotations that could be considered part of the language definition. 2.jj Glossary entry: The text of a Glossary entry -- this text will also appear in Annex N, ``Glossary''. 2.kk Discussion: In general, RM9X text appears in the normal font, whereas AARM-only text appears in a smaller font. Notes also appear in the smaller font, as recommended by ISO/IEC style guidelines. Ada examples are also usually printed in a smaller font. 2.ll If you have trouble finding things, be sure to use the index. {italics, like this} Each defined term appears there, and also in italics, like this. Syntactic categories defined in BNF are also indexed. 2.mm A definition marked ``[distributed]'' is the main definition for a term whose complete definition is given in pieces distributed throughout the document. The pieces are marked ``[partial]'' or with a phrase explaining what cases the partial definition applies to. 1.1 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. 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 implemen- tation 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 This International Standard contains thirteen sections, fourteen annexes, and an index. 2 {core language} The core of the Ada language consists of: 3 Sections 1 through 13 4 Annex A, ``Predefined Language Environment'' 5 Annex B, ``Interface to Other Languages'' 6 Annex J, ``Obsolescent Features'' 7 {Specialized Needs Annexes} {Annex (Specialized Needs)} {application areas} 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, ``Safety and Security'' 14 {normative} {Annex (normative)} 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 Each clause or 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 {informative} {non-normative: see informative} {Annex (informative)} The following Annexes are informative: 19 Annex K, ``Language-Defined Attributes'' 20 Annex L, ``Language-Defined Pragmas'' 21 Annex M, ``Implementation-Defined Characteristics'' 22 Annex N, ``Glossary'' 23 Annex P, ``Syntax Summary'' 23.a Discussion: The idea of the Specialized Needs Annexes is that implementations can choose to target certain application areas. For example, an implementation specifically targeted to embedded machines might support the application-specific features for Real-time Systems, but not the application-specific features for Information Systems. 23.b The Specialized Needs Annexes extend the core language only in ways that users, implementations, and standards bodies are allowed to extend the language; for example, via additional library units, attributes, representation items (see 13.1), pragmas, and constraints on semantic details that are left unspecified by the core language. Many implementations already provide much of the functionality defined by Specialized Needs Annexes; our goal is to increase uniformity among implementations by defining standard ways of providing the functionality. 23.c We recommend that the validation procedures allow implemen- tations to validate the core language, plus any set of the Specialized Needs Annexes. We recommend that implementations not be allowed to validate a portion of one of the Specialized Needs Annexes, although implementations can, of course, provide unvalidated support for such portions. We have designed the Specialized Needs Annexes assuming that this recommendation is followed. Thus, our decisions about what to include and what not to include in those annexes are based on the assumption that each annex is validated in an ``all-or-nothing'' manner. 23.d An implementation may, of course, support extensions that are different from (but possibly related to) those defined by one of the Specialized Needs Annexes. We recommend that, where appropriate, implementations do this by adding library units that are children of existing language-defined library packages. 23.e An implementation should not provide extensions that conflict with those defined in the Specialized Needs Annexes, in the following sense: Suppose an implementation supports a certain error-free program that uses only functionality defined in the core and in the Specialized Needs Annexes. The implementation should ensure that that program will still be error free in some possible full implementation of all of the Specialized Needs Annexes, and that the semantics of the program will not change. For example, an implementation should not provide a package with the same name as one defined in one of the Specialized Needs Annexes, but that behaves differently, even if that implementation does not claim conformance to that Annex. 23.f Note that the Specialized Needs Annexes do not conflict with each other; it is the intent that a single implementation can conform to all of them. 24 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: Language Design Principles 24.a These are not rules of the language, but guiding principles or goals used in defining the rules of the language. In some cases, the goal is only partially met; such cases are explained. 24.b This is not part of the definition of the language, and does not appear in the RM9X. Syntax 25 {syntax (under Syntax heading)} {grammar (under Syntax heading)} {context free grammar (under Syntax heading)} {BNF (Backus-Naur Form) (under Syntax heading)} {Backus-Naur Form (BNF) (under Syntax heading)} Syntax rules (indented). Name Resolution Rules 26 {name resolution rules} {overloading rules} {resolution rules} Compile-time rules that are used in name resolution, including overload resolution. 26.a Discussion: These rules are observed at compile time. (We say ``observed'' rather than ``checked,'' because these rules are not individually checked. They are really just part of the Legality Rules in Section 8 that require exactly one interpretation of each constituent of a complete context.) The only rules used in overload resolution are the Syntax Rules and the Name Resolution Rules. 26.b When dealing with non-overloadable declarations it sometimes makes no semantic difference whether a given rule is a Name Resolution Rule or a Legality Rule, and it is sometimes difficult to decide which it should be. We generally make a given rule a Name Resolution Rule only if it has to be. For example, ``The name, if any, in a raise_statement shall be the name of an exception.'' is under ``Legality Rules.'' Legality Rules 27 {legality rules} {compile-time error} {error (compile-time)} Rules that are enforced at compile time. {legal (construct)} {illegal (construct)} A construct is legal if it obeys all of the Legality Rules. 27.a Discussion: These rules are not used in overload resolution. 27.b Note that run-time errors are always attached to exceptions; for example, it is not ``illegal'' to divide by zero, it just raises an exception. Static Semantics 28 {static semantics} {compile-time semantics} A definition of the compile-time effect of each construct. 28.a Discussion: The most important compile-time effects represent the effects on the symbol table associated with declarations (implicit or explicit). In addition, we use this heading as a bit of a grab bag for equivalences, package specifications, etc. For example, this is where we put statements like so-and-so is equivalent to such-and-such. (We ought to try to really mean it when we say such things!) Similarly, statements about magically-generated implicit declarations go here. These rules are generally written as statements of fact about the semantics, rather than as a you-shall-do-such-and-such sort of thing. Post-Compilation Rules 29 {post-compilation rules} {post-compilation error} {post-compilation rules} {link-time error: see post-compilation error} {error (link-time)} Rules that are enforced before running a partition. {legal (partition)} {illegal (partition)} A partition is legal if its compilation units are legal and it obeys all of the Post-Compilation Rules. 29.a Discussion: It is not specified exactly when these rules are checked, so long as they are checked for any given partition before that partition starts running. An implementation may choose to check some such rules at compile time, and reject compilation_units accordingly. Alternatively, an implementation may check such rules when the partition is created (usually known as ``link time''), or when the partition is mapped to a particular piece of hardware (but before the partition starts running). Dynamic Semantics 30 {dynamic semantics} {run-time semantics} {run-time error} {error (run-time)} A definition of the run-time effect of each construct. 30.a Discussion: This heading describes what happens at run time. Run-time checks, which raise exceptions upon failure, are described here. Each item that involves a run-time check is marked with the name of the check -- these are the same check names that are used in a pragma Suppress. Principle: Every check should have a name, usable in a pragma Suppress. Bounded (Run-Time) Errors 31 {bounded error} {bounded error} Situations that result in bounded (run-time) errors (see 1.1.5). 31.a Discussion: The ``bounds'' of each such error are described here -- that is, we characterize the set of all possible behaviors that can result from a bounded error occurring at run time. Erroneous Execution 32 {erroneous execution} {erroneous execution} Situations that result in erroneous execution (see 1.1.5). Implementation Requirements 33 {implementation requirements} Additional requirements for conforming implementations. 33.a Discussion: ...as opposed to rules imposed on the programmer. An example might be, ``The smallest representable duration, Duration'Small, shall not be greater than twenty milliseconds.'' 33.b It's really just an issue of how the rule is worded. We could write the same rule as ``The smallest representable duration is an implementation-defined value less than or equal to 20 milliseconds'' and then it would be under ``Static Semantics.'' Documentation Requirements 34 {documentation requirements} {documentation requirements} Documentation requirements for conforming implementations. 34.a Discussion: These requirements are beyond those that are implicitly specified by the phrase ``implementation defined''. The latter require documentation as well, but we don't repeat these cases under this heading. Usually this heading is used for when the description of the documentation requirement is longer and does not correspond directly to one, narrow normative sentence. Metrics 35 {metrics} {metrics} Metrics that are specified for the time/space properties of the execution of certain language constructs. Implementation Permissions 36 {implementation permissions} Additional permissions given to the implementer. 36.a Discussion: For example, ``The implementation is allowed to impose further restrictions on the record aggregates allowed in code statements.'' When there are restrictions on the permission, those restrictions are given here also. For example, ``An implementation is allowed to restrict the kinds of subprograms that are allowed to be main subprograms. However, it shall support at least parameterless procedures.'' -- we don't split this up between here and ``Implementation Requirements.'' Implementation Advice 37 {implementation advice} {advice} 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. 37.a Implementation defined: Whether or not each recommendation given in Implementation Advice is followed. 37.b Discussion: The advice generally shows the intended implementation, but the implementer is free to ignore it. The implementer is the sole arbiter of whether or not the advice has been obeyed, if not, whether the reason is a good one, and whether the required documentation is sufficient. {ACVC [Ada Compiler Validation Capability]} {Ada Compiler Validation Capability [ACVC]} It would be wrong for the ACVC to enforce any of this advice. 37.c For example, ``Whenever possible, the implementation should choose a value no greater than fifty microseconds for the smallest representable duration, Duration'Small.'' 37.d We use this heading, for example, when the rule is so low level or implementation-oriented as to be untestable. We also use this heading when we wish to encourage implementations to behave in a certain way in most cases, but we do not wish to burden implementations by requiring the behavior. NOTES 38 (1) {notes} 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. 39.a Discussion: The next three headings list all language changes between Ada 83 and Ada 9X. Language changes are any change that changes the set of text strings that are legal Ada programs, or changes the meaning of any legal program. Wording changes, such as changes in terminology, are not language changes. Each language change falls into one of the following three categories: Inconsistencies With Ada 83 39.b {inconsistencies with Ada 83} {inconsistencies with Ada 83} This heading lists all of the upward inconsistencies between Ada 83 and Ada 9X. Upward inconsistencies are situations in which a legal Ada 83 program is a legal Ada 9X program with different semantics. This type of upward incompatibility is the worst type for users, so we only tolerate it in rare situations. 39.c (Note that the semantics of a program is not the same thing as the behavior of the program. Because of Ada's indeterminacy, the ``semantics'' of a given feature describes a set of behaviors that can be exhibited by that feature. The set can contain more than one allowed behavior. Thus, when we ask whether the semantics changes, we are asking whether the set of behaviors changes.) 39.d This is not part of the definition of the language, and does not appear in the RM9X. Incompatibilities With Ada 83 39.e {incompatibilities with Ada 83} {incompatibilities with Ada 83} This heading lists all of the upward incompatibilities between Ada 83 and Ada 9X, except for the ones listed under ``Inconsistencies With Ada 83'' above. These are the situations in which a legal Ada 83 program is illegal in Ada 9X. We do not generally consider a change that turns erroneous execution into an exception, or into an illegality, to be upwardly incompatible. 39.f This is not part of the definition of the language, and does not appear in the RM9X. Extensions to Ada 83 39.g {extensions to Ada 83} {extensions to Ada 83} This heading is used to list all upward compatible language changes; that is, language extensions. These are the situations in which a legal Ada 9X program is not a legal Ada 83 program. The vast majority of language changes fall into this category. 39.h This is not part of the definition of the language, and does not appear in the RM9X. 39.i As explained above, the next heading does not represent any language change: Wording Changes From Ada 83 39.j {wording changes from Ada 83} This heading lists some of the non-semantic changes between RM83 and the RM9X. It is incomplete; we have not attempted to list all wording changes, but only the ``interesting'' ones. 39.k This is not part of the definition of the language, and does not appear in the RM9X. 1.1.3 Conformity of an Implementation with the Standard Implementation Requirements 1 {conformance (of an implementation with the Standard)} A conforming implementation shall: 1.a Discussion: {implementation} The implementation is the software and hardware that implements the language. This includes compiler, linker, operating system, hardware, etc. 1.b We first define what it means to ``conform'' in general -- basically, the implementation has to properly implement the normative rules given throughout the standard. Then we define what it means to conform to a Specialized Needs Annex -- the implementation must support the core features plus the features of that Annex. Finally, we define what it means to ``conform to the Standard'' -- this requires support for the core language, and allows partial (but not conflicting) support for the Specialized Needs Annexes. 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); 3.a Implementation defined: Capacity limitations of the implementation. 4 Identify all programs or program units that contain errors whose detection is required by this International Standard; 4.a Discussion: Note that we no longer use the term ``rejection'' of programs or program units. We require that programs or program units with errors or that exceed some capacity limit be ``identified.'' The way in which errors or capacity problems are reported is not specified. 4.b An implementation is allowed to use standard error-recovery techniques. We do not disallow such techniques from being used across compilation_unit or compilation boundaries. 4.c See also the Implementation Requirements of 10.2, which disallow the execution of illegal partitions. 5 Supply all language-defined library units required by this International Standard; 5.a Implementation Note: An implementation cannot add to or modify the visible part of a language-defined library unit, except where such permission is explicitly granted, unless such modifications are semantically neutral with respect to the client compilation units of the library unit. An implementation defines the contents of the private part and body of language-defined library units. 5.b An implementation can add with_clauses and use_clauses, since these modifications are semantically neutral to clients. (The implementation might need with_clauses in order to implement the private part, for example.) Similarly, an implementation can add a private part even in cases where a private part is not shown in the standard. Explicit declarations can be provided implicitly or by renaming, provided the changes are semantically neutral. 5.c {italics (implementation-defined)} Wherever in the standard the text of a language-defined library unit contains an italicized phrase starting with ``implementation-defined'', the implementation's version will replace that phrase with some implementation-defined text that is syntactically legal at that place, and follows any other applicable rules. 5.d Note that modifications are permitted, even if there are other tools in the environment that can detect the changes (such as a program library browser), so long as the modifications make no difference with respect to the static or dynamic semantics of the resulting programs, as defined by the 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; 6.a Implementation defined: Variations from the standard that are impractical to avoid given the implementation's execution environment. 6.b Reason: The ``impossible or impractical'' wording comes from AI-325. It takes some judgement and common sense to interpret this. Restricting compilation units to less than 4 lines is probably unreasonable, whereas restricting them to less than 4 billion lines is probably reasonable (at least given today's technology). We do not know exactly where to draw the line, so we have to make the rule vague. 7 Specify all such variations in the manner prescribed by this International Standard. 8 {external effect (of the execution of an Ada program)} {effect (external)} The external effect of the execution of an Ada program is defined in terms of its interactions with its external environment. {external interaction} 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. 10.a Implementation defined: Which code_statements cause external interactions. 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; 12.a Discussion: By ``result returned'' we mean to include function results and values returned in [in] out parameters. 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. 14.a To be honest: Also other uses of imported and exported entities, as defined by the implementation, if the implementation supports such pragmas. 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. 15.a Ramification: There is no need to produce any of the ``internal effects'' defined for the semantics of the program -- all of these can be optimized away -- so long as an appropriate sequence of external interactions is produced. 15.b Discussion: See also 11.6 which specifies various liberties associated with optimizations in the presence of language-defined checks, that could change the external effects that might be produced. These alternative external effects are still consistent with the standard, since 11.6 is part of the standard. 15.c Note also that we only require ``an appropriate sequence of external interactions'' rather than ``the same sequence...'' An optimizer may cause a different sequence of external interactions to be produced than would be produced without the optimizer, so long as the new sequence still satisfies the requirements of the standard. For example, optimization might affect the relative rate of progress of two concurrent tasks, thereby altering the order in which two external interactions occur. 15.d Note that RM83 explicitly mentions the case of an ``exact effect'' of a program, but since so few programs have their effects defined that exactly, we don't even mention this ``special'' case. In particular, almost any program that uses floating point or tasking has to have some level of inexactness in the specification of its effects. And if one includes aspects of the timing of the external interactions in the external effect of the program (as is appropriate for a real-time language), no ``exact effect'' can be specified. For example, if two external interactions initiated by a single task are separated by a ``delay 1.0;'' then the language rules imply that the two external interactions have to be separated in time by at least one second, as defined by the clock associated with the delay_ relative_statement. This in turn implies that the time at which an external interaction occurs is part of the characterization of the external interaction, at least in some cases, again making the specification of the required ``exact effect'' impractical. 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. 16.a Discussion: The last sentence defines what it means to say that an implementation conforms to a Specialized Needs Annex, namely, only by supporting all capabilities required by the Annex. 17 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. 17.a Discussion: The last sentence of the preceding paragraph defines what an implementation is allowed to do when it does not "conform" to a Specialized Needs Annex. In particular, the sentence forbids implementations from providing a construct with the same name as a corresponding construct in a Specialized Needs Annex but with a different syntax (e.g., an extended syntax) or quite different semantics. The phrase concerning "more limited in capability" is intended to give permission to provide a partial implementation, such as not implementing a subprogram in a package or having a restriction not permitted by an implementation that conforms to the Annex. For example, a partial implementation of the package Ada.Decimal might have Decimal.Max_Decimal_Digits as 15 (rather than the required 18). This allows a partial implementation to grow to a fully conforming implementation. 17.b A restricted implementation might be restricted by not providing some subprograms specified in one of the packages defined by an Annex. In this case, a program that tries to use the missing subprogram will usually fail to compile. Alternatively, the implementation might declare the subprogram as abstract, so it cannot be called. {Program_Error (raised by failure of run-time check)} Alternatively, a subprogram body might be implemented just to raise Program_Error. The advantage of this approach is that a program to be run under a fully conforming Annex implementation can be checked syntactically and semantically under an implementation that only partially supports the Annex. Finally, an implementation might provide a package declaration without the corresponding body, so that programs can be compiled, but partitions cannot be built and executed. 17.c To ensure against wrong answers being delivered by a partial implementation, implementers are required to raise an exception when a program attempts to use an unsupported capability and this can be detected only at run time. For example, a partial implementation of Ada.Decimal might require the length of the Currency string to be 1, and hence, an exception would be raised if a subprogram were called in the package Edited_Output with a length greater than 1. Documentation Requirements 18 {documentation requirements} {implementation defined} {unspecified} {specified (not!)} {implementation-dependent: see unspecified} {documentation (required of an implementation)} 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. 18.a Discussion: We used to use the term ``implementation dependent'' instead of ``unspecified''. However, that sounded too much like ``implementation defined''. Furthermore, the term ``unspecified'' is used in the ANSI C and POSIX standards for this purpose, so that is another advantage. We also use ``not specified'' and ``not specified by the language'' as synonyms for ``unspecified.'' The documentation requirement is the only difference between implementation defined and unspecified. 18.b Note that the ``set of possible effects'' can be ``all imaginable effects'', as is the case with erroneous execution. 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. 19.a Discussion: For example, if the standard says that library unit elaboration order is implementation defined, the implementation might describe (in its user's manual) the algorithm it uses to determine the elaboration order. On the other hand, the implementation might provide a command that produces a description of the elaboration order for a partition upon request from the user. It is also acceptable to provide cross references to existing documentation (for example, a hardware manual), where appropriate. 19.b Note that dependence of a program on implementation-defined or unspecified functionality is not defined to be an error; it might cause the program to be less portable, however. Implementation Advice 20 {Program_Error (raised by failure of run-time check)} If an implementation detects the use of an unsupported Specialized Needs Annex feature at run time, it should raise Program_Error if feasible. 20.a Reason: The reason we don't require Program_Error is that there are situations where other exceptions might make sense. For example, if the Real Time Systems Annex requires that the range of System.Priority include at least 30 values, an implementation could conform to the Standard (but not to the Annex) if it supported only 12 values. Since the rules of the language require Constraint_Error to be raised for out-of-range values, we cannot require Program_Error to be raised instead. 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. 21.a Implementation Note: If an implementation has support code (``run-time system code'') that is needed for the execution of user-defined code, it can put that support code in child packages of System. Otherwise, it has to use some trick to avoid polluting the user's namespace. It is important that such tricks not be available to user-defined code (not in the standard mode, at least) -- that would defeat the purpose. 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. 22.a Discussion: A conforming implementation can partially support a Specialized Needs Annex. Such an implementation does not conform to the Annex, but it does conform to the Standard. 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 {syntax (notation)} {grammar (notation)} {context free grammar (notation)} {BNF (Backus-Naur Form) (notation)} {Backus-Naur Form (BNF) (notation)} 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 return_statement ::= return [expression]; 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 {italics (syntax rules)} 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.a Discussion: {LR(1)} {ambiguous grammar} {grammar (resolution of ambiguity)} {grammar (ambiguous)} The grammar given in the RM9X is not LR(1). In fact, it is ambiguous; the ambiguities are resolved by the overload resolution rules (see 8.6). 14.b We often use ``if'' to mean ``if and only if'' in definitions. For example, if we define ``photogenic'' by saying, ``A type is photogenic if it has the following properties...,'' we mean that a type is photogenic if and only if it has those properties. It is usually clear from the context, and adding the ``and only if'' seems too cumbersome. 14.c When we say, for example, ``a declarative_item of a declarative_part'', we are talking about a declarative_item immediately within that declarative_part. When we say ``a declarative_item in, or within, a declarative_part'', we are talking about a declarative_item anywhere in the declarative_part, possibly deeply nested within other declarative_parts. (This notation doesn't work very well for names, since the name ``of'' something also has another meaning.) 14.d When we refer to the name of a language-defined entity (for example, Duration), we mean the language-defined entity even in programs where the declaration of the language-defined entity is hidden by another declaration. For example, when we say that the expected type for the expression of a delay_relative_statement is Duration, we mean the language-defined type Duration that is declared in Standard, not some type Duration the user might have declared. 15 {syntactic category} 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 {Construct} [glossary entry]A construct is a piece of text (explicit or implicit) that is an instance of a syntactic category defined under ``Syntax.'' 16.a Ramification: For example, an expression is a construct. A declaration is a construct, whereas the thing declared by a declaration is an ``entity.'' 16.b Discussion: ``Explicit'' and ``implicit'' don't mean exactly what you might think they mean: The text of an instance of a generic is considered explicit, even though it does not appear explicitly (in the non-technical sense) in the program text, and even though its meaning is not defined entirely in terms of that text. 17 {constituent (of a construct)} A constituent of a construct is the construct itself, or any construct appearing within it. 18 {arbitrary order} 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. {type conversion [arbitrary order]} {conversion [arbitrary order]} [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.] 18.a Discussion: Programs will be more portable if their external effect does not depend on the particular order chosen by an implementation. 18.b Ramification: Additional reordering permissions are given in 11.6, ``Exceptions and Optimization''. 18.c There is no requirement that the implementation always choose the same order in a given kind of situation. In fact, the implementation is allowed to choose a different order for two different executions of the same construct. However, we expect most implementations will behave in a relatively predictable manner in most situations. 18.d Reason: The ``sequential order'' wording is intended to allow the programmer to rely on ``benign'' side effects. For example, if F is a function that returns a unique integer by incrementing some global and returning the result, a call such as P(F, F) is OK if the programmer cares only that the two results of F are unique; the two calls of F cannot be executed in parallel, unless the compiler can prove that parallel execution is equivalent to some sequential order. 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 {compile-time error} {error (compile-time)} {link-time error: see post-compilation error} {error (link-time)} 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. 4.a Ramification: See, for example, 10.1.3, ``Subunits of Compilation Units'', for some errors that are detected only after compilation. Implementations are allowed, but not required, to detect post compilation rules at compile time when possible. 5 Errors that are required to be detected at run time by the execution of an Ada program; 6 {run-time error} {error (run-time)} 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. {bounded error} The errors of this category are called bounded errors. {Program_Error (raised by failure of run-time check)} 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 {erroneous execution} 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. 10.a Ramification: Executions are erroneous, not programs or parts of programs. Once something erroneous happens, the execution of the entire program is erroneous from that point on, and potentially before given possible reorderings permitted by 11.6 and elsewhere. We cannot limit it to just one partition, since partitions are not required to live in separate address spaces. (But implementations are encouraged to limit it as much as possible.) 10.b Suppose a program contains a pair of things that will be executed ``in an arbitrary order.'' It is possible that one order will result in something sensible, whereas the other order will result in erroneous execution. If the implementation happens to choose the first order, then the execution is not erroneous. This may seem odd, but it is not harmful. 10.c Saying that something is erroneous is semantically equivalent to saying that the behavior is unspecified. However, ``erroneous'' has a slightly more disapproving flavor. Implementation Permissions 11 [{mode of operation (nonstandard)} {nonstandard mode} 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. {mode of operation (standard)} {standard mode} 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.] 11.a Discussion: These permissions are designed to authorize explicitly the support for alternative modes. Of course, nothing we say can prevent them anyway, but this (redundant) paragraph is designed to indicate that such alternative modes are in some sense ``approved'' and even encouraged where they serve the specialized needs of a given user community, so long as the standard mode, designed to foster maximum portability, is always available. Implementation Advice 12 {Program_Error (raised by failure of run-time check)} If an implementation detects a bounded error or erroneous execution, it should raise Program_Error. Wording Changes From Ada 83 12.a Some situations that are erroneous in Ada 83 are no longer errors at all. For example, depending on the parameter passing mechanism when unspecified is possibly non-portable, but not erroneous. 12.b Other situations that are erroneous in Ada 83 are changed to be bounded errors. In particular, evaluating an uninitialized scalar variable is a bounded error. {Program_Error (raised by failure of run-time check)} The possible results are to raise Program_Error (as always), or to produce a machine-representable value (which might not be in the subtype of the variable). {Constraint_Error (raised by failure of run-time check)} Violating a Range_Check or Overflow_Check raises Constraint_Error, even if the value came from an uninitialized variable. This means that optimizers can no longer ``assume'' that all variables are initialized within their subtype's range. Violating a check that is suppressed remains erroneous. 12.c The ``incorrect order dependences'' category of errors is removed. All such situations are simply considered potential non-portabilities. This category was removed due to the difficulty of defining what it means for two executions to have a ``different effect.'' For example, if a function with a side-effect is called twice in a single expression, it is not in principle possible for the compiler to decide whether the correctness of the resulting program depends on the order of execution of the two function calls. A compile time warning might be appropriate, but raising of Program_ Error at run time would not be. 1.2 Normative References 1 {references} {bibliography} 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} {646:1991, ISO/IEC standard} {character set standard (7-bit)} ISO/IEC 646:1991, Information technology -- ISO 7-bit coded character set for information interchange. 3 {ISO/IEC 1539:1991} {1539:1991, ISO/IEC standard} {FORTRAN standard} ISO/IEC 1539:1991, Information technology -- Programming languages -- FORTRAN. 4 {ISO 1989:1985} {1989:1985, ISO standard} {COBOL standard} ISO 1989:1985, Programming languages -- COBOL. 5 {ISO/IEC 6429:1992} {6429:1992, ISO/IEC standard} {character set standard (control functions)} ISO/IEC 6429:1992, Information technology -- Control functions for coded graphic character sets. 6 {ISO/IEC 8859-1:1987} {8859-1:1987, ISO/IEC standard} {character set standard (8-bit)} 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} {9899:1990, ISO/IEC standard} {C standard} ISO/IEC 9899:1990, Programming languages -- C. 8 {ISO/IEC 10646-1:1993} {10646-1:1993, ISO/IEC standard} {character set standard (16-bit)} ISO/IEC 10646-1:1993, Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane. 8.a Discussion: {POSIX} POSIX, Portable Operating System Interface (POSIX) -- Part 1: System Application Program Interface (API) [C Language], The Institute of Electrical and Electronics Engineers, 1990. 1.3 Definitions 1 {italics (terms introduced or defined)} 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''. 1.a Discussion: The index contains an entry for every defined term. 1.b Glossary entry: Each term defined in Annex N is marked like this. 1.c Discussion: Here are some AARM-only definitions: {Ada Rapporteur Group (ARG)} {ARG} The Ada Rapporteur Group (ARG) interprets the RM83. {Ada Issue (AI)} {AI} An Ada Issue (AI) is a numbered ruling from the ARG. {Ada Commentary Integration Document (ACID)} {ACID} The Ada Commentary Integration Document (ACID) is an edition of RM83 in which clearly marked insertions and deletions indicate the effect of integrating the approved AIs. {Uniformity Rapporteur Group (URG)} {URG} The Uniformity Rapporteur Group (URG) issues recommendations intended to increase uniformity across Ada implementations. {Uniformity Issue (UI)} {UI} A Uniformity Issue (UI) is a numbered recommendation from the URG. Section 2: Lexical Elements 1 [The text of a program consists of the texts of one or more compilations. The text of a compilation is a sequence of lexical elements, each composed of characters; the rules of composition are given in this section. Pragmas, which provide certain information for the compiler, are also described in this section.] 2.1 Character Set 1 {character set} The only characters allowed outside of comments are the graphic_characters and format_effectors. 1.a Ramification: Any character, including an other_control_ function, is allowed in a comment. 1.b Note that this rule doesn't really have much force, since the implementation can represent characters in the source in any way it sees fit. For example, an implementation could simply define that what seems to be a non-graphic, non-format-effector character is actually a representation of the space character. 1.c Discussion: It is our intent to follow the terminology of ISO 10646 BMP where appropriate, and to remain compatible with the character classifications defined in A.3, ``Character Handling''. Note that our definition for graphic_character is more inclusive than that of ISO 10646-1. Syntax 2 character ::= graphic_character | format_effector | other_control_function 3 graphic_character ::= identifier_letter | digit | space_character | special\ _character Static Semantics 4 The character repertoire for the text of an Ada program consists of the collection of characters called the Basic Multilingual Plane (BMP) of the ISO 10646 Universal Multiple-Octet Coded Character Set, plus a set of format_ effectors and, in comments only, a set of other_control_functions; the coded representation for these characters is implementation defined [(it need not be a representation defined within ISO-10646-1)]. 4.a Implementation defined: The coded representation for the text of an Ada program. 5 The description of the language definition in this International Standard uses the graphic symbols defined for Row 00: Basic Latin and Row 00: Latin-1 Supplement of the ISO 10646 BMP; these correspond to the graphic symbols of ISO 8859-1 (Latin-1); no graphic symbols are used in this International Standard for characters outside of Row 00 of the BMP. The actual set of graphic symbols used by an implementation for the visual representation of the text of an Ada program is not specified. {unspecified [partial]} 6 The categories of characters are defined as follows: 7 {identifier_letter} identifier_letter upper_case_identifier_letter | lower_case_identifier_letter 7.a Discussion: We use identifier_letter instead of simply letter because ISO 10646 BMP includes many other characters that would generally be considered "letters." 8 {upper_case_identifier_letter} upper_case_identifier_letter Any character of Row 00 of ISO 10646 BMP whose name begins ``Latin Capital Letter''. 9 {lower_case_identifier_letter} lower_case_identifier_letter Any character of Row 00 of ISO 10646 BMP whose name begins ``Latin Small Letter''. 9.a To be honest: The above rules do not include the ligatures AE and ae. However, the intent is to include these characters as identifier letters. This problem was pointed out by a comment from the Netherlands. 10 {digit} digit One of the characters 0, 1, 2, 3, 4, 5, 6, 7, 8, or 9. 11 {space_character} space_character The character of ISO 10646 BMP named ``Space''. 12 {special_character} special_character Any character of the ISO 10646 BMP that is not reserved for a control function, and is not the space_character, an identifier_letter, or a digit. 12.a Ramification: Note that the no break space and soft hyphen are special_characters, and therefore graphic_characters. They are not the same characters as space and hyphen-minus. 13 {format_effector} format_effector The control functions of ISO 6429 called character tabulation (HT), line tabulation (VT), carriage return (CR), line feed (LF), and form feed (FF). {control character: see also format_effector} 14 {other_control_function} other_control_function Any control function, other than a format_effector, that is allowed in a comment; the set of other_control_functions allowed in comments is implementation defined. 14.a Implementation defined: The control functions allowed in comments. {control character: see also other_control_function} 15 {names of special_characters} {special_character (names)} The following names are used when referring to certain special_characters: {quotation mark} {number sign} {ampersand} {apostrophe} {tick} {left parenthesis} {right parenthesis} {asterisk} {multiply} {plus sign} {comma} {hyphen-minus} {minus} {full stop} {dot} {point} {solidus} {divide} {colon} {semicolon} {less-than sign} {equals sign} {greater-than sign} {low line} {underline} {vertical line} {left square bracket} {right square bracket} {left curly bracket} {right curly bracket} 15.a Discussion: These are the ones that play a special role in the syntax of Ada 9X, or in the syntax rules; we don't bother to define names for all characters. The first name given is the name from ISO 10646-1; the subsequent names, if any, are those used within the standard, depending on context. symbol name symbol name " quotation mark : colon # number sign ; semicolon & ampersand < less-than sign ' apostrophe, tick = equals sign ( left parenthesis > greater-than sign ) right parenthesis _ low line, underline * asterisk, multiply | vertical line + plus sign [ left square bracket , comma ] right square bracket - hyphen-minus, minus { left curly bracket . full stop, dot, point } right curly bracket / solidus, divide Implementation Permissions 16 In a nonstandard mode, the implementation may support a different character repertoire[; in particular, the set of characters that are considered identifier_letters can be extended or changed to conform to local conventions]. 16.a Ramification: If an implementation supports other character sets, it defines which characters fall into each category, such as ``identifier_letter,'' and what the corresponding rules of this section are, such as which characters are allowed in the text of a program. NOTES 17 (1) Every code position of ISO 10646 BMP that is not reserved for a control function is defined to be a graphic_character by this International Standard. This includes all code positions other than 0000 - 001F, 007F - 009F, and FFFE - FFFF. 18 (2) The language does not specify the source representation of programs. 18.a Discussion: Any source representation is valid so long as the implementer can produce an (information-preserving) algorithm for translating both directions between the representation and the standard character set. (For example, every character in the standard character set has to be representable, even if the output devices attached to a given computer cannot print all of those characters properly.) From a practical point of view, every implementer will have to provide some way to process the ACVC. It is the intent to allow source representations, such as parse trees, that are not even linear sequences of characters. It is also the intent to allow different fonts: reserved words might be in bold face, and that should be irrelevant to the semantics. Extensions to Ada 83 18.b {extensions to Ada 83} Ada 9X allows 8-bit and 16-bit characters, as well as implementation-specified character sets. Wording Changes From Ada 83 18.c The syntax rules in this clause are modified to remove the emphasis on basic characters vs. others. (In this day and age, there is no need to point out that you can write programs without using (for example) lower case letters.) In particular, character (representing all characters usable outside comments) is added, and basic_graphic_character, other_special_character, and basic_character are removed. Special_character is expanded to include Ada 83's other_special_character, as well as new 8-bit characters not present in Ada 83. Note that the term ``basic letter'' is used in A.3, ``Character Handling'' to refer to letters without diacritical marks. 18.d Character names now come from ISO 10646. 18.e We use identifier_letter rather than letter since ISO 10646 BMP includes many "letters' that are not permitted in identifiers (in the standard mode). 2.2 Lexical Elements, Separators, and Delimiters Static Semantics 1 {text of a program} The text of a program consists of the texts of one or more compilations. {lexical element} {token: see lexical element} The text of each compilation is a sequence of separate lexical elements. Each lexical element is formed from a sequence of characters, and is either a delimiter, an identifier, a reserved word, a numeric_literal, a character_literal, a string_literal, or a comment. The meaning of a program depends only on the particular sequences of lexical elements that form its compilations, excluding comments. 2 The text of a compilation is divided into {line} lines. {end of a line} In general, the representation for an end of line is implementation defined. 2.a Implementation defined: The representation for an end of line. However, a sequence of one or more format_effectors other than character tabulation (HT) signifies at least one end of line. 3 {separator} [In some cases an explicit separator is required to separate adjacent lexical elements.] A separator is any of a space character, a format effector, or the end of a line, as follows: 3.a Discussion: It might be useful to define ``white space'' and use it here. 4 A space character is a separator except within a comment, a string_literal, or a character_literal. 5 Character tabulation (HT) is a separator except within a comment. 6 The end of a line is always a separator. 7 One or more separators are allowed between any two adjacent lexical elements, before the first of each compilation, or after the last. At least one separator is required between an identifier, a reserved word, or a numeric_literal and an adjacent identifier, reserved word, or numeric_ literal. 8 {delimiter} A delimiter is either one of the following special characters 9 & ' ( ) * + , - . / : ; < = > | 10 {compound delimiter} or one of the following compound delimiters each composed of two adjacent special characters 11 => .. ** := /= >= <= << >> <> 12 Each of the special characters listed for single character delimiters is a single delimiter except if this character is used as a character of a compound delimiter, or as a character of a comment, string_literal, character_literal, or numeric_literal. 13 The following names are used when referring to compound delimiters: 14 delimiter name => arrow .. double dot ** double star, exponentiate := assignment (pronounced: ``becomes'') /= inequality (pronounced: ``not equal'') >= greater than or equal <= less than or equal << left label bracket >> right label bracket <> box Implementation Requirements 15 An implementation shall support lines of at least 200 characters in length, not counting any characters used to signify the end of a line. An implementation shall support lexical elements of at least 200 characters in length. The maximum supported line length and lexical element length are implementation defined. 15.a Implementation defined: Maximum supported line length and lexical element length. 15.b Discussion: From URG recommendation. 2.3 Identifiers 1 Identifiers are used as names. Syntax 2 identifier ::= identifier_letter {[underline] letter_or_digit} 3 letter_or_digit ::= identifier_letter | digit 4 An identifier shall not be a reserved word. Static Semantics 5 All characters of an identifier are significant, including any underline character. {case insensitive} Identifiers differing only in the use of corresponding upper and lower case letters are considered the same. 5.a Discussion: Two of the letters of ISO 8859-1 appear only as lower case, "sharp s" and "y with diaeresis." These two letters have no corresponding upper case letter (in particular, they are not considered equivalent to one another). Implementation Permissions 6 In a nonstandard mode, an implementation may support other upper/lower case equivalence rules for identifiers[, to accommodate local conventions]. Examples 7 Examples of identifiers: 8 Count X Get_Symbol Ethelyn Marion Snobol_4 X1 Page_Count Store_Next_Item Wording Changes From Ada 83 8.a We no longer include reserved words as identifiers. This is not a language change. In Ada 83, identifier included reserved words. However, this complicated several other rules (for example, regarding implementation-defined attributes and pragmas, etc.). We now explicitly allow certain reserved words for attribute designators, to make up for the loss. 8.b Ramification: Because syntax rules are relevant to overload resolution, it means that if it looks like a reserved word, it is not an identifier. As a side effect, implementations cannot use reserved words as implementation-defined attributes or pragma names. 2.4 Numeric Literals 1 {literal (numeric)} There are two kinds of numeric_literals, real literals and integer literals. {real literal} A real literal is a numeric_ literal that includes a point; {integer literal} an integer literal is a numeric_literal without a point. Syntax 2 numeric_literal ::= decimal_literal | based_literal NOTES 3 (3) The type of an integer literal is universal_integer. The type of a real literal is universal_real. 2.4.1 Decimal Literals 1 {literal (decimal)} A decimal_literal is a numeric_literal in the conventional decimal notation (that is, the base is ten). Syntax 2 decimal_literal ::= numeral [.numeral] [exponent] 3 numeral ::= digit {[underline] digit} 4 exponent ::= E [+] numeral | E - numeral 5 An exponent for an integer literal shall not have a minus sign. 5.a Ramification: Although this rule is in this subclause, it applies also to the next subclause. Static Semantics 6 An underline character in a numeric_literal does not affect its meaning. The letter E of an exponent can be written either in lower case or in upper case, with the same meaning. 6.a Ramification: Although these rules are in this subclause, they apply also to the next subclause. 7 An exponent indicates the power of ten by which the value of the decimal_ literal without the exponent is to be multiplied to obtain the value of the decimal_literal with the exponent. Examples 8 Examples of decimal literals: 9 12 0 1E6 123_456 -- integer literals 12.0 0.0 0.456 3.14159_26 -- real literals Wording Changes From Ada 83 9.a We have changed the syntactic category name integer to be numeral. We got this idea from ACID. It avoids the confusion between this and integers. (Other places don't offer similar confusions. For example, a string_literal is different from a string.) 2.4.2 Based Literals 1 [{literal (based)} {binary literal} {base 2 literal} {binary (literal)} {octal literal} {base 8 literal} {octal (literal)} {hexadecimal literal} {base 16 literal} {hexadecimal (literal)} A based_literal is a numeric_ literal expressed in a form that specifies the base explicitly.] Syntax 2 based_literal ::= base # based_numeral [.based_numeral] # [exponent] 3 base ::= numeral 4 based_numeral ::= extended_digit {[underline] extended_digit} 5 extended_digit ::= digit | A | B | C | D | E | F Legality Rules 6 {base} The base (the numeric value of the decimal numeral preceding the first #) shall be at least two and at most sixteen. The extended_digits A through F represent the digits ten through fifteen, respectively. The value of each extended_digit of a based_literal shall be less than the base. Static Semantics 7 The conventional meaning of based notation is assumed. An exponent indicates the power of the base by which the value of the based_literal without the exponent is to be multiplied to obtain the value of the based_ literal with the exponent. The base and the exponent, if any, are in decimal notation. 8 The extended_digits A through F can be written either in lower case or in upper case, with the same meaning. Examples 9 Examples of based literals: 10 2#1111_1111# 16#FF# 016#0ff# -- integer literal\ s of value 255 16#E#E1 2#1110_0000# -- integer literal\ s of value 224 16#F.FF#E+2 2#1.1111_1111_1110#E11 -- real literals o\ f value 4095.0 Wording Changes From Ada 83 10.a The rule about which letters are allowed is now encoded in BNF, as suggested by Mike Woodger. This is clearly more readable. 2.5 Character Literals 1 [A character_literal is formed by enclosing a graphic character between two apostrophe characters.] Syntax 2 character_literal ::= 'graphic_character' NOTES 3 (4) A character_literal is an enumeration literal of a character type. See 3.5.2. Examples 4 Examples of character literals: 5 'A' '*' ''' ' ' Wording Changes From Ada 83 5.a The definitions of the values of literals are in Sections 3 and 4, rather than here, since it requires knowledge of types. 2.6 String Literals 1 [A string_literal is formed by a sequence of graphic characters (possibly none) enclosed between two quotation marks used as string brackets. They are used to represent operator_symbols (see 6.1), values of a string type (see 4.2), and array subaggregates (see 4.3.3). {quoted string: see string_ literal}] Syntax 2 string_literal ::= "{string_element}" 3 string_element ::= "" | non_quotation_mark_graphic_character 4 A string_element is either a pair of quotation marks (""), or a single graphic_character other than a quotation mark. Static Semantics 5 {sequence of characters (of a string_literal)} The sequence of characters of a string_literal is formed from the sequence of string_elements between the bracketing quotation marks, in the given order, with a string_element that is "" becoming a single quotation mark in the sequence of characters, and any other string_element being reproduced in the sequence. 6 {null string literal} A null string literal is a string_literal with no string_elements between the quotation marks. NOTES 7 (5) An end of line cannot appear in a string_literal. Examples 8 Examples of string literals: 9 "Message of the day:" "" -- a null string literal " " "A" """" -- three string literals of length 1 "Characters such as $, %, and } are allowed in string literals" Wording Changes From Ada 83 9.a The wording has been changed to be strictly lexical. No mention is made of string or character values, since string_literals are also used to represent operator_symbols, which don't have a defined value. 9.b The syntax is described differently. 2.7 Comments 1 A comment starts with two adjacent hyphens and extends up to the end of the line. Syntax 2 comment ::= --{non_end_of_line_character} 3 A comment may appear on any line of a program. Static Semantics 4 The presence or absence of comments has no influence on whether a program is legal or illegal. Furthermore, comments do not influence the meaning of a program; their sole purpose is the enlightenment of the human reader. Examples 5 Examples of comments: 6 -- the last sentence above echoes the Algol 68 report end; -- processing of Line is complete -- a long comment may be split onto -- two or more consecutive lines ---------------- the first two hyphens start the comment 2.8 Pragmas 1 {Pragma} [glossary entry]A pragma is a compiler directive. There are language-defined pragmas that give instructions for optimization, listing control, etc. An implementation may support additional (implementation- defined) pragmas. Syntax 2 pragma ::= pragma identifier [(pragma_argument_association {, pragma_argument_assoc\ iation})]; 3 pragma_argument_association ::= [pragma_argument_identifier =>] name | [pragma_argument_identifier =>] expression 4 In a pragma, any pragma_argument_associations without a pragma_ argument_identifier shall precede any associations with a pragma_ argument_identifier. 5 Pragmas are only allowed at the following places in a program: 6 After a semicolon delimiter, but not within a formal_part or discriminant_part. 7 At any place where the syntax rules allow a construct defined by a syntactic category whose name ends with "declaration", "statement", "clause", or "alternative", or one of the syntactic categories variant or exception_handler; but not in place of such a construct. Also at any place where a compilation_unit would be allowed. 8 Additional syntax rules and placement restrictions exist for specific pragmas. 8.a Discussion: The above rule is written in text, rather than in BNF; the syntactic category pragma is not used in any BNF syntax rule. 8.b Ramification: A pragma is allowed where a generic_formal_ parameter_declaration is allowed. 9 {name (of a pragma)} {pragma name} The name of a pragma is the identifier following the reserved word pragma. {pragma argument} {argument of a pragma} The name or expression of a pragma_argument_association is a pragma argument. 10 {identifier specific to a pragma} {pragma, identifier specific to} An identifier specific to a pragma is an identifier that is used in a pragma argument with special meaning for that pragma. 10.a To be honest: Whenever the syntax rules for a given pragma allow "identifier" as an argument of the pragma, that identifier is an identifier specific to that pragma. Static Semantics 11 If an implementation does not recognize the name of a pragma, then it has no effect on the semantics of the program. Inside such a pragma, the only rules that apply are the Syntax Rules. 11.a To be honest: This rule takes precedence over any other rules that imply otherwise. 11.b Ramification: Note well: this rule applies only to pragmas whose name is not recognized. If anything else is wrong with a pragma (at compile time), the pragma is illegal. This is true whether the pragma is language defined or implementation defined. 11.c For example, an expression in an unrecognized pragma does not cause freezing, even though the rules in 13.14, ``Freezing Rules'' say it does; the above rule overrules those other rules. On the other hand, an expression in a recognized pragma causes freezing, even if this makes something illegal. 11.d For another example, an expression that would be ambiguous is not illegal if it is inside an unrecognized pragma. 11.e Note, however, that implementations have to recognize pragma Inline(Foo) and freeze things accordingly, even if they choose to never do inlining. 11.f Obviously, the contradiction needs to be resolved one way or the other. The reasons for resolving it this way are: The implementation is simple -- the compiler can just ignore the pragma altogether. The interpretation of constructs appearing inside implementation-defined pragmas is implementation defined. For example: ``pragma Mumble(X);''. If the current implementation has never heard of Mumble, then it doesn't know whether X is a name, an expression, or an identifier specific to the pragma Mumble. 11.g To be honest: The syntax of individual pragmas overrides the general syntax for pragma. 11.h Ramification: Thus, an identifier specific to a pragma is not a name, syntactically; if it were, the visibility rules would be invoked, which is not what we want. 11.i This also implies that named associations do not allow one to give the arguments in an arbitrary order -- the order given in the syntax rule for each individual pragma must be obeyed. However, it is generally possible to leave out earlier arguments when later ones are given; for example, this is allowed by the syntax rule for pragma Import (see B.1, ``Interfacing Pragmas''). As for subprogram calls, positional notation precedes named notation. 11.j Note that Ada 83 had no pragmas for which the order of named associations mattered, since there was never more than one argument that allowed named associations. 11.k To be honest: The interpretation of the arguments of implementation-defined pragmas is implementation defined. However, the syntax rules have to be obeyed. Dynamic Semantics 12 {execution [pragma]} {elaboration [pragma]} Any pragma that appears at the place of an executable construct is executed. Unless otherwise specified for a particular pragma, this execution consists of the evaluation of each evaluable pragma argument in an arbitrary order. 12.a Ramification: For a pragma that appears at the place of an elaborable construct, execution is elaboration. 12.b An identifier specific to a pragma is neither a name nor an expression -- such identifiers are not evaluated (unless an implementation defines them to be evaluated in the case of an implementation-defined pragma). 12.c The ``unless otherwise specified'' part allows us (and implementations) to make exceptions, so a pragma can contain an expression that is not evaluated. Note that pragmas in type_ definitions may contain expressions that depend on discriminants. 12.d When we wish to define a pragma with some run-time effect, we usually make sure that it appears in an executable context; otherwise, special rules are needed to define the run-time effect and when it happens. Implementation Requirements 13 The implementation shall give a warning message for an unrecognized pragma name. 13.a Ramification: An implementation is also allowed to have modes in which a warning message is suppressed, or in which the presence of an unrecognized pragma is a compile-time error. Implementation Permissions 14 An implementation may provide implementation-defined pragmas; the name of an implementation-defined pragma shall differ from those of the language-defined pragmas. 14.a Implementation defined: Implementation-defined pragmas. 14.b Ramification: The semantics of implementation-defined pragmas, and any associated rules (such as restrictions on their placement or arguments), are, of course, implementation defined. Implementation-defined pragmas may have run-time effects. 15 An implementation may ignore an unrecognized pragma even if it violates some of the Syntax Rules, if detecting the syntax error is too complex. 15.a Reason: Many compilers use extra post-parsing checks to enforce the syntax rules, since the Ada syntax rules are not LR(k) (for any k). (The grammar is ambiguous, in fact.) This paragraph allows them to ignore an unrecognized pragma, without having to perform such post-parsing checks. Implementation Advice 16 Normally, implementation-defined pragmas should have no semantic effect for error-free programs; that is, if the implementation-defined pragmas are removed from a working program, the program should still be legal, and should still have the same semantics. 16.a Ramification: Note that ``semantics'' is not the same as ``effect;'' as explained in 1.1.3, the semantics defines a set of possible effects. 16.b Note that adding a pragma to a program might cause an error (either at compile time or at run time). On the other hand, if the language-specified semantics for a feature are in part implementation defined, it makes sense to support pragmas that control the feature, and that have real semantics; thus, this paragraph is merely a recommendation. 17 Normally, an implementation should not define pragmas that can make an illegal program legal, except as follows: 18 A pragma used to complete a declaration, such as a pragma Import; 19 A pragma used to configure the environment by adding, removing, or replacing library_items. 19.a Ramification: For example, it is OK to support Interface, System_Name, Storage_Unit, and Memory_Size pragmas for upward compatibility reasons, even though all of these pragmas can make an illegal program legal. (The latter three can affect legality in a rather subtle way: They affect the value of named numbers in System, and can therefore affect the legality in cases where static expressions are required.) 19.b On the other hand, adding implementation-defined pragmas to a legal program can make it illegal. For example, a common kind of implementation-defined pragma is one that promises some property that allows more efficient code to be generated. If the promise is a lie, it is best if the user gets an error message. Incompatibilities With Ada 83 19.c {incompatibilities with Ada 83} In Ada 83, ``bad'' pragmas are ignored. In Ada 9X, they are illegal, except in the case where the name of the pragma itself is not recognized by the implementation. Extensions to Ada 83 19.d {extensions to Ada 83} Implementation-defined pragmas may affect the legality of a program. Wording Changes From Ada 83 19.e Implementation-defined pragmas may affect the run-time semantics of the program. This was always true in Ada 83 (since it was not explicitly forbidden by RM83), but it was not clear, because there was no definition of ``executing'' or ``elaborating'' a pragma. Syntax 20 The forms of List, Page, and Optimize pragmas are as follows: 21 pragma List(identifier); 22 pragma Page; 23 pragma Optimize(identifier); 24 [Other pragmas are defined throughout this International Standard, and are summarized in Annex L.] 24.a Ramification: The language-defined pragmas are supported by every implementation, although ``supporting'' some of them (for example, Inline) requires nothing more than checking the arguments, since they act only as advice to the implementation. Static Semantics 25 A pragma List takes one of the identifiers On or Off as the single argument. This pragma is allowed anywhere a pragma is allowed. It specifies that listing of the compilation is to be continued or suspended until a List pragma with the opposite argument is given within the same compilation. The pragma itself is always listed if the compiler is producing a listing. 26 A pragma Page is allowed anywhere a pragma is allowed. It specifies that the program text which follows the pragma should start on a new page (if the compiler is currently producing a listing). 27 A pragma Optimize takes one of the identifiers Time, Space, or Off as the single argument. This pragma is allowed anywhere a pragma is allowed, and it applies until the end of the immediately enclosing declarative region, or for a pragma at the place of a compilation_unit, to the end of the compilation. It gives advice to the implementation as to whether time or space is the primary optimization criterion, or that optional optimizations should be turned off. [It is implementation defined how this advice is followed.] 27.a Implementation defined: Effect of pragma Optimize. 27.b Discussion: For example, a compiler might use Time vs. Space to control whether generic instantiations are implemented with a macro-expansion model, versus a shared-generic-body model. 27.c We don't define what constitutes an ``optimization'' -- in fact, it cannot be formally defined in the context of Ada. One compiler might call something an optional optimization, whereas another compiler might consider that same thing to be a normal part of code generation. Thus, the programmer cannot rely on this pragma having any particular portable effect on the generated code. Some compilers might even ignore the pragma altogether. Examples 28 Examples of pragmas: 29 pragma List(Off); -- turn off listing generation pragma Optimize(Off); -- turn off optional optimizations pragma Inline(Set_Mask); -- generate code for Set_Mask inline pragma Suppress(Range_Check, On => Index); -- turn off range checking on In\ dex Extensions to Ada 83 29.a {extensions to Ada 83} The Optimize pragma now allows the identifier Off to request that normal optimization be turned off. 29.b An Optimize pragma may appear anywhere pragmas are allowed. Wording Changes From Ada 83 29.c We now describe the pragmas Page, List, and Optimize here, to act as examples, and to remove the normative material from Annex L, ``Language-Defined Pragmas'', so it can be entirely an informative annex. 2.9 Reserved Words Syntax 1 2 {reserved word} The following are the reserved words (ignoring upper/lower case distinctions): 2.a Discussion: Reserved words have special meaning in the syntax. In addition, certain reserved words are used as attribute names. 2.b The syntactic category identifier no longer allows reserved words. We have added the few reserved words that are legal explicitly to the syntax for attribute_reference. Allowing identifier to include reserved words has been a source of confusion for some users, and differs from the way they are treated in the C and Pascal language definitions. abort else new return abs elsif not reverse abstract end null accept entry select access exception separate aliased exit of subtype all or and for others tagged array function out task at terminate generic package then begin goto pragma type body private if procedure case in protected until constant is use raise declare range when delay limited record while delta loop rem with digits renames do mod requeue xor NOTES 3 (6) The reserved words appear in lower case boldface in this International Standard, except when used in the designator of an attribute (see 4.1.4). Lower case boldface is also used for a reserved word in a string_literal used as an operator_symbol. This is merely a convention -- programs may be written in whatever typeface is desired and available. Incompatibilities With Ada 83 3.a {incompatibilities with Ada 83} The following words are not reserved in Ada 83, but are reserved in Ada 9X: abstract, aliased, protected, requeue, tagged, until. Wording Changes From Ada 83 3.b The clause entitled ``Allowed Replacements of Characters'' has been moved to Annex J, ``Obsolescent Features''. Section 3: Declarations and Types 1 This section describes the types in the language and the rules for declaring constants, variables, and named numbers. 3.1 Declarations 1 {entity [partial]} The language defines several kinds of named entities that are declared by declarations. {name [partial]} The entity's name is defined by the declaration, usually by a defining_identifier, but sometimes by a defining_character_literal or defining_operator_symbol. 2 There are several forms of declaration. A basic_declaration is a form of declaration defined as follows. Syntax 3 basic_declaration ::= type_declaration | subtype_declaration | object_declaration | number_declaration | subprogram_declaration | abstract_subprogram_declaration | package_declaration | renaming_declaration | exception_declaration | generic_declaration | generic_instantiation 4 defining_identifier ::= identifier Static Semantics 5 {Declaration} [glossary entry]A declaration is a language construct that associates a name with (a view of) an entity. {explicit declaration} {implicit declaration} A declaration may appear explicitly in the program text (an explicit declaration), or may be suppose