Contents Index 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
4
5
6
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.
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
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
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
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).)
Contents Index Search Previous Next Legal