1.1.2 Structure

Discussion: {AI05-0299-1} What Ada 83 called a “chapter” and Ada 95 (and Ada 2005) called a “section” is called a “clause” in this Standard. Similarly, what Ada 83 called a “section” and Ada 95 (and Ada 2005) called a “clause” is called a “subclause” in this Standard. Confused yet? This terminology is out of our hands; it is (and was) forced by ever-changing ISO rules for drafting Standards.

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.

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.

{AI95-00114-01} We recommend that the certification procedures allow implementations to certify the core language, plus any set of the Specialized Needs Annexes. We recommend that implementations not be allowed to certify a portion of one of the Specialized Needs Annexes, although implementations can, of course, provide uncertified 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 certified in an “all-or-nothing” manner.

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.

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.

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. 

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.

{AI05-0005-1} This is not part of the definition of the language, and does not appear in the Ada 2012 RM. 

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 Clause 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.

When dealing with nonoverloadable 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.” 

Discussion: These rules are not used in overload resolution.

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. 

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. 

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). 

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. 

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. 

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.”

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.”

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. 

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 defined: Whether or not each recommendation given in Implementation Advice is followed — see M.3, “Implementation Advice” for a listing.

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. It would be wrong for the ACATS to enforce any of this advice.

For example, “Whenever possible, the implementation should choose a value no greater than fifty microseconds for the smallest representable duration, Duration'Small.”

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. 

Discussion:  

The next three headings list all language changes between Ada 83 and Ada 95. 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:

This heading lists all of the upward inconsistencies between Ada 83 and Ada 95. Upward inconsistencies are situations in which a legal Ada 83 program is a legal Ada 95 program with different semantics. This type of upward incompatibility is the worst type for users, so we only tolerate it in rare situations.

(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.)

This is not part of the definition of the language, and does not appear in the Ada 95, Ada 2005, or Ada 2012 RM. 

This heading lists all of the upward incompatibilities between Ada 83 and Ada 95, 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 95. We do not generally consider a change that turns erroneous execution into an exception, or into an illegality, to be upwardly incompatible.

This is not part of the definition of the language, and does not appear in the Ada 95, Ada 2005, or Ada 2012 RM. 

This heading is used to list all upward compatible language changes; that is, language extensions. These are the situations in which a legal Ada 95 program is not a legal Ada 83 program. The vast majority of language changes fall into this category.

This is not part of the definition of the language, and does not appear in the Ada 95, Ada 2005, or Ada 2012 RM.

 

As explained above, the next heading does not represent any language change: 

This heading lists some of the nonsemantic changes between the Ada 83 RM and the Ada 95 RM. It is incomplete; we have not attempted to list all wording changes, but only the “interesting” ones.

This is not part of the definition of the language, and does not appear in the Ada 95, Ada 2005, or Ada 2012 RM. 

Discussion:  

The next three headings list all language changes between Ada 95 and Ada 2005 (the language defined by the Ada 95 standard plus Technical Corrigendum 1 plus Amendment 1). Each language change falls into one of the following three categories: 

This heading lists all of the upward inconsistencies between Ada 95 and Ada 2005. Upward inconsistencies are situations in which a legal Ada 95 program is a legal Ada 2005 program with different semantics.

{AI05-0005-1} Inconsistencies marked with Corrigendum: are corrections to the original Ada 95 definition introduced by Corrigendum 1. Inconsistencies marked with Amendment Correction: are corrections to the original Ada 95 definition added by Amendment 1. Formally, these are inconsistencies caused by Ada Issues classified as Binding Interpretations; implementations of Ada 95 are supposed to follow these corrections, not the original flawed language definition. Thus, these strictly speaking are not inconsistencies between Ada 95 and Ada 2005. Practically, however, they very well may be, as early Ada 95 implementations might not follow the recommendation. Inconsistencies so marked are not portable between Ada 95 implementations, while usually Ada 2005 will have more clearly defined behavior. Therefore, we document these for completeness.

This is not part of the definition of the language, and does not appear in the Ada 2005 or Ada 2012 RM. 

This heading lists all of the upward incompatibilities between Ada 95 and Ada 2005, except for the ones listed under “Inconsistencies With Ada 95” above. These are the situations in which a legal Ada 95 program is illegal in Ada 2005.

{AI05-0005-1} As with inconsistencies, incompatibilities marked with Corrigendum: are corrections to the original Ada 95 definition introduced by Corrigendum 1. Incompatibilities marked with Amendment Correction: are corrections to the original Ada 95 definition added by Amendment 1. Formally, these are incompatibilities caused by Ada Issues classified as Binding Interpretations; implementations of Ada 95 are supposed to follow these corrections, not the original flawed language definition. Thus, these strictly speaking are not incompatibilities between Ada 95 and Ada 2005. Practically, however, they very well may be, as early Ada 95 implementations might not follow the recommendation. Therefore, some Ada 95 implementations may be able to compile the examples, while others might not. In contrast, Ada 2005 compilers will have consistent behavior. Therefore, we document these for completeness.

This is not part of the definition of the language, and does not appear in the Ada 2005 or Ada 2012 RM. 

This heading is used to list all upward compatible language changes; that is, language extensions. These are the situations in which a legal Ada 2005 program is not a legal Ada 95 program. The vast majority of language changes fall into this category.

{AI05-0005-1} As with incompatibilities, extensions marked with Corrigendum: are corrections to the original Ada 95 definition introduced by Corrigendum 1. Extensions marked with Amendment Correction: are corrections to the original Ada 95 definition added by Amendment 1. Formally, these are extensions allowed by Ada Issues classified as Binding Interpretations. As corrections, implementations of Ada 95 are allowed to implement these extensions. Thus, these strictly speaking are not extensions of Ada 95; they're part of Ada 95. Practically, however, they very well may be extensions, as early Ada 95 implementations might not implement the extension. Therefore, some Ada 95 implementations may be able to compile the examples, while others might not. In contrast, Ada 2005 compilers will always support the extensions. Therefore, we document these for completeness.

This is not part of the definition of the language, and does not appear in the Ada 2005 or Ada 2012 RM.

 

As explained above, the next heading does not represent any language change: 

This heading lists some of the nonsemantic changes between the Ada 95 RM and the Ada 2005 RM. This heading lists only “interesting” changes (for instance, editorial corrections are not listed). Changes which come from Technical Corrigendum 1 are marked Corrigendum; unmarked changes come from Amendment 1.

This is not part of the definition of the language, and does not appear in the Ada 2005 or Ada 2012 RM. 

Discussion:  

The next three headings list all language changes between Ada 2005 (the language defined by the Ada 95 standard plus Technical Corrigendum 1 plus Amendment 1) and Ada 2012 (the language defined by the third edition of the Standard). Each language change falls into one of the following three categories: 

This heading lists all of the upward inconsistencies between Ada 2005 and Ada 2012. Upward inconsistencies are situations in which a legal Ada 2005 program is a legal Ada 2012 program with different semantics.

Inconsistencies marked with Correction: are corrections to the original Ada 2005 definition added by the third edition of the Standard. Formally, these are inconsistencies caused by Ada Issues classified as Binding Interpretations; implementations of Ada 2005 are supposed to follow these corrections, not the original flawed language definition. Thus, these strictly speaking are not inconsistencies between Ada 2005 and Ada 2012. Practically, however, they very well may be, as early Ada 2005 implementations might not follow the recommendation. Inconsistencies so marked are not portable between Ada 2005 implementations, while usually Ada 2012 will have more clearly defined behavior. Therefore, we document these for completeness.

This is not part of the definition of the language, and does not appear in the Ada 2012 RM. 

This heading lists all of the upward incompatibilities between Ada 2005 and Ada 2012, except for the ones listed under “Inconsistencies With Ada 2005” above. These are the situations in which a legal Ada 2005 program is illegal in Ada 2012.

As with inconsistencies, incompatibilities marked with Correction: are corrections to the original Ada 2005 definition added by the third edition. Formally, these are incompatibilities caused by Ada Issues classified as Binding Interpretations; implementations of Ada 2005 are supposed to follow these corrections, not the original flawed language definition. Thus, these strictly speaking are not incompatibilities between Ada 2005 and Ada 2012. Practically, however, they very well may be, as early Ada 2005 implementations might not follow the recommendation. Therefore, some Ada 2005 implementations may be able to compile the examples, while others might not. In contrast, Ada 2012 compilers will have consistent behavior. Therefore, we document these for completeness.

This is not part of the definition of the language, and does not appear in the Ada 2012 RM. 

This heading is used to list all upward compatible language changes; that is, language extensions. These are the situations in which a legal Ada 2012 program is not a legal Ada 2005 program. The vast majority of language changes fall into this category.

As with incompatibilities, extensions marked with Correction: are corrections to the original Ada 2005 definition added by the third edition. Formally, these are extensions allowed by Ada Issues classified as Binding Interpretations. As corrections, implementations of Ada 2005 (and sometimes Ada 95) are allowed to implement these extensions. Thus, these strictly speaking are not extensions of Ada 2005; they're part of Ada 2005. Practically, however, they very well may be extensions, as early Ada 2005 implementations might not implement the extension. Therefore, some Ada 2005 implementations may be able to compile the examples, while others might not. In contrast, Ada 2012 compilers will always support the extensions. Therefore, we document these for completeness.

This is not part of the definition of the language, and does not appear in the Ada 2012 RM.

 

As explained above, the next heading does not represent any language change: 

This heading lists some of the nonsemantic changes between the Ada 2005 RM and the Ada 2012 RM. This heading lists only “interesting” changes (for instance, editorial corrections are not listed). Items marked Correction: come from Ada Issues classified as Binding Interpretations and strictly speaking belong to Ada 2005; other items only belong to Ada 2012.

This is not part of the definition of the language, and does not appear in the Ada 2012 RM. 

Discussion:  

The next three headings list all language changes between original Ada 2012 (the language defined by unmodified ISO/IEC 8652:2012(E)) and current Ada 2012 (the language defined by ISO/IEC 8652:2012(E) as corrected by the Corrigendum ISO/IEC 8652:2012/Cor 1:2016). Each language change falls into one of the following three categories: 

This heading lists all of the upward inconsistencies between original and current Ada 2012. Upward inconsistencies are situations in which a legal original Ada 2012 program is a legal current Ada 2012 program with different semantics.

Inconsistencies marked with Corrigendum: are corrections to the original Ada 2012 definition added by Technical Corrigendum 1 to Ada 2012. Formally, these are inconsistencies caused by Ada Issues classified as Binding Interpretations; implementations of Ada 2012 are supposed to follow these corrections, not the original flawed language definition. Thus, these strictly speaking are not inconsistencies between current and original Ada 2012. Practically, however, they very well may be, as early Ada 2012 implementations might not follow the recommendation. Inconsistencies so marked are not portable between Ada 2012 implementations. Therefore, we document these for completeness.

This is not part of the definition of the language, and does not appear in any version of the Ada RM. 

This heading lists all of the upward incompatibilities between original and current Ada 2012, except for the ones listed under “Inconsistencies With Ada 2012” above. These are the situations in which a legal original Ada 2012 program is illegal in current Ada 2012.

As with inconsistencies, incompatibilities marked with Corrigendum: are corrections to the original Ada 2012 definition added by Corrigendum 1 to Ada 2012 Formally, these are incompatibilities caused by Ada Issues classified as Binding Interpretations; implementations of Ada 2012 are supposed to follow these corrections, not the original flawed language definition. Thus, these strictly speaking are not incompatibilities between current and original Ada 2012. Practically, however, they very well may be, as early Ada 2012 implementations might not follow the recommendation. Therefore, some Ada 2012 implementations may be able to compile the examples, while others might not. Therefore, we document these for completeness.

This is not part of the definition of the language, and does not appear in any version of the Ada RM. 

This heading is used to list all upward compatible language changes; that is, language extensions. These are the situations in which a legal current Ada 2012 program is not a legal original Ada 2012 program. The vast majority of language changes fall into this category.

As with incompatibilities, extensions marked with Corrigendum: are corrections to the original Ada 2012 definition added by Corrigendum 1 to Ada 2012. Formally, these are extensions allowed by Ada Issues classified as Binding Interpretations. As corrections, implementations of Ada 2012 (and sometimes Ada 95) are allowed to implement these extensions. Thus, these strictly speaking are not extensions of Ada 2012; they're part of Ada 2012. Practically, however, they very well may be extensions, as early Ada 2012 implementations might not implement the extension. Therefore, some Ada 2012 implementations may be able to compile the examples, while others might not. Therefore, we document these for completeness.

This is not part of the definition of the language, and does not appear in any version of the Ada RM.

 

As explained above, the next heading does not represent any language change: 

This heading lists some of the nonsemantic changes between the original and corrected Ada 2012 RM. This heading lists only “interesting” changes (for instance, editorial corrections are not listed). Items marked Corrigendum: are included in Corrigendum 1 to Ada 2012. These items come from Ada Issues classified as Binding Interpretations and strictly speaking belong to Ada 2012.

This is not part of the definition of the language, and does not appear in any version of the Ada RM.