Annotated Ada Reference Manual — Legal Information
Contents   Index   References   Search   Previous   Next 

8.1 Declarative Region

Static Semantics

1
{declarative region (of a construct)} For each of the following constructs, there is a portion of the program text called its declarative region, [within which nested declarations can occur]:
2
any declaration, other than that of an enumeration type, that is not a completion [of a previous declaration];
3
a block_statement;
4
a loop_statement;
4.1/2
{AI95-00318-02} an extended_return_statement;
5
an accept_statement;
6
an exception_handler.
7
The declarative region includes the text of the construct together with additional text determined [(recursively)], as follows: 
8
If a declaration is included, so is its completion, if any.
9
If the declaration of a library unit [(including Standard — see 10.1.1)] is included, so are the declarations of any child units [(and their completions, by the previous rule)]. The child declarations occur after the declaration.
10
If a body_stub is included, so is the corresponding subunit.
11
If a type_declaration is included, then so is a corresponding record_representation_clause, if any. 
11.a
Reason: This is so that the component_declarations can be directly visible in the record_representation_clause.
12
The declarative region of a declaration is also called the declarative region of any view or entity declared by the declaration.
12.a
Reason: The constructs that have declarative regions are the constructs that can have declarations nested inside them. Nested declarations are declared in that declarative region. The one exception is for enumeration literals; although they are nested inside an enumeration type declaration, they behave as if they were declared at the same level as the type. 
12.b
To be honest: A declarative region does not include parent_unit_names.
12.c
Ramification: A declarative region does not include context_clauses.
13
{occur immediately within} {immediately within} {within (immediately)} {immediately enclosing} {enclosing (immediately)} A declaration occurs immediately within a declarative region if this region is the innermost declarative region that encloses the declaration (the immediately enclosing declarative region), not counting the declarative region (if any) associated with the declaration itself. 
13.a
Discussion: Don't confuse the declarative region of a declaration with the declarative region in which it immediately occurs. 
14
[{local to} A declaration is local to a declarative region if the declaration occurs immediately within the declarative region.] [An entity is local to a declarative region if the entity is declared by a declaration that is local to the declarative region.] 
14.a
Ramification: "Occurs immediately within" and "local to" are synonyms (when referring to declarations).
14.b
Thus, “local to” applies to both declarations and entities, whereas “occurs immediately within” only applies to declarations. We use this term only informally; for cases where precision is required, we use the term "occurs immediately within", since it is less likely to cause confusion. 
15
{global to} A declaration is global to a declarative region if the declaration occurs immediately within another declarative region that encloses the declarative region. An entity is global to a declarative region if the entity is declared by a declaration that is global to the declarative region. 
NOTES
16
1  The children of a parent library unit are inside the parent's declarative region, even though they do not occur inside the parent's declaration or body. This implies that one can use (for example) "P.Q" to refer to a child of P whose defining name is Q, and that after "use P;" Q can refer (directly) to that child.
17
2  As explained above and in 10.1.1, “Compilation Units - Library Units”, all library units are descendants of Standard, and so are contained in the declarative region of Standard. They are not inside the declaration or body of Standard, but they are inside its declarative region.
18
3  For a declarative region that comes in multiple parts, the text of the declarative region does not contain any text that might appear between the parts. Thus, when a portion of a declarative region is said to extend from one place to another in the declarative region, the portion does not contain any text that might appear between the parts of the declarative region. 
18.a
Discussion: It is necessary for the things that have a declarative region to include anything that contains declarations (except for enumeration type declarations). This includes any declaration that has a profile (that is, subprogram_declaration, subprogram_body, entry_declaration, subprogram_renaming_declaration, formal_subprogram_declaration, access-to-subprogram type_declaration), anything that has a discriminant_part (that is, various kinds of type_declaration), anything that has a component_list (that is, record type_declaration and record extension type_declaration), and finally the declarations of task and protected units and packages.

Wording Changes from Ada 83

18.b
It was necessary to extend Ada 83's definition of declarative region to take the following Ada 95 features into account: 
18.c
Child library units.
18.d
Derived types/type extensions — we need a declarative region for inherited components and also for new components.
18.e
All the kinds of types that allow discriminants.
18.f
Protected units.
18.g
Entries that have bodies instead of accept statements.
18.h
The choice_parameter_specification of an exception_handler.
18.i
The formal parameters of access-to-subprogram types.
18.j
Renamings-as-body. 
18.k
Discriminated and access-to-subprogram type declarations need a declarative region. Enumeration type declarations cannot have one, because you don't have to say "Color.Red" to refer to the literal Red of Color. For other type declarations, it doesn't really matter whether or not there is an associated declarative region, so for simplicity, we give one to all types except enumeration types.
18.l
We now say that an accept_statement has its own declarative region, rather than being part of the declarative region of the entry_declaration, so that declarative regions are properly nested regions of text, so that it makes sense to talk about "inner declarative regions," and "...extends to the end of a declarative region." Inside an accept_statement, the name of one of the parameters denotes the parameter_specification of the accept_statement, not that of the entry_declaration. If the accept_statement is nested within a block_statement, these parameter_specifications can hide declarations of the block_statement. The semantics of such cases was unclear in RM83. 
18.m
To be honest: Unfortunately, we have the same problem for the entry name itself — it should denote the accept_statement, but accept_statements are not declarations. They should be, and they should hide the entry from all visibility within themselves. 
18.n
Note that we can't generalize this to entry_bodies, or other bodies, because the declarative_part of a body is not supposed to contain (explicit) homographs of things in the declaration. It works for accept_statements only because an accept_statement does not have a declarative_part.
18.o
To avoid confusion, we use the term “local to” only informally in Ada 95. Even RM83 used the term incorrectly (see, for example, RM83-12.3(13)).
18.p
In Ada 83, (root) library units were inside Standard; it was not clear whether the declaration or body of Standard was meant. In Ada 95, they are children of Standard, and so occur immediately within Standard's declarative region, but not within either the declaration or the body. (See RM83-8.6(2) and RM83-10.1.1(5).) 

Wording Changes from Ada 95

18.q/2
{AI95-00318-02} Extended_return_statement (see 6.5) is added to the list of constructs that have a declarative region. 
Contents   Index   References   Search   Previous   Next 
Ada-Europe Sponsored by Ada-Europe