3.11 Declarative Parts
1
[A declarative_part contains
declarative_items (possibly none).]
Syntax
2
declarative_part ::= {
declarative_item}
3
declarative_item ::=
basic_declarative_item |
body
4/1
{
8652/0009}
{
AI95-00137-01}
basic_declarative_item ::=
basic_declaration |
aspect_clause representation_clause |
use_clause5
body ::= proper_body |
body_stub
6
proper_body ::=
subprogram_body |
package_body |
task_body |
protected_body
Static Semantics
6.1/2
{
AI95-00420-01}
The list of declarative_items
of a declarative_part is called the declaration
list of the declarative_part.{declaration
list (declarative_part) [partial]} Dynamic Semantics
7
{elaboration (declarative_part)
[partial]} The elaboration of a
declarative_part
consists of the elaboration of the
declarative_items,
if any, in the order in which they are given in the
declarative_part.
8
{elaborated}
An elaborable construct is in the
elaborated
state after the normal completion of its elaboration. Prior to that,
it is
not yet elaborated.
8.a
Ramification: The elaborated state is
only important for bodies; certain uses of a body raise an exception
if the body is not yet elaborated.
8.b
Note that "prior" implies before the
start of elaboration, as well as during elaboration.
8.c
The use of the term "normal completion"
implies that if the elaboration propagates an exception or is aborted,
the declaration is not elaborated. RM83 missed the aborted case.
9
{Elaboration_Check
[partial]} {check,
language-defined (Elaboration_Check)} For
a construct that attempts to use a body, a check (Elaboration_Check)
is performed, as follows:
10/1
- {8652/0014}
{AI95-00064-01}
For a call to a (non-protected) subprogram that has an explicit body,
a check is made that the body subprogram_body
is already elaborated. This check and the evaluations of any actual parameters
of the call are done in an arbitrary order.
10.a
Discussion: AI83-00180 specifies that
there is no elaboration check for a subprogram defined by a pragma
Interface (or equivalently, pragma Import).
AI83-00430 specifies that there is no elaboration check for an enumeration
literal. AI83-00406 specifies that the evaluation of parameters and the
elaboration check occur in an arbitrary order. AI83-00406 applies to
generic instantiation as well (see below).
10.a.1/1
{
8652/0014}
{
AI95-00064-01}
A subprogram can be completed by a renaming-as-body,
and we need to make an elaboration check on such a body, so we use “body”
rather than subprogram_body above.
11
- For a call to a protected operation
of a protected type (that has a body — no check is performed if
a pragma Import applies to the protected type),
a check is made that the protected_body is
already elaborated. This check and the evaluations of any actual parameters
of the call are done in an arbitrary order.
11.a
Discussion: A protected type has only
one elaboration “bit,” rather than one for each operation,
because one call may result in evaluating the barriers of other entries,
and because there are no elaborable declarations between the bodies of
the operations. In fact, the elaboration of a protected_body
does not elaborate the enclosed bodies, since they are not considered
independently elaborable.
11.b
Note that there is no elaboration check when
calling a task entry. Task entry calls are permitted even before the
associated task_body has been seen. Such calls
are simply queued until the task is activated and reaches a corresponding
accept_statement. We considered a similar
rule for protected entries — simply queuing all calls until the
protected_body was seen, but felt it was not
worth the possible implementation overhead, particularly given that there
might be multiple instances of the protected type.
12
- For the activation of a task, a check
is made by the activator that the task_body
is already elaborated. If two or more tasks are being activated together
(see 9.2), as the result of the elaboration
of a declarative_part or the initialization
for the object created by an allocator, this check is done for all of
them before activating any of them.
12.a
Reason: As specified by AI83-00149, the
check is done by the activator, rather than by the task itself. If it
were done by the task itself, it would be turned into a Tasking_Error
in the activator, and the other tasks would still be activated.
13
- For the instantiation of a generic
unit that has a body, a check is made that this body is already elaborated.
This check and the evaluation of any explicit_generic_actual_parameters
of the instantiation are done in an arbitrary order.
14
{Program_Error (raised
by failure of run-time check)} The exception
Program_Error is raised if any of these checks fails.
Extensions to Ada 83
14.a
{
extensions to Ada 83}
The
syntax for
declarative_part is modified to
remove the ordering restrictions of Ada 83; that is, the distinction
between
basic_declarative_items and
later_declarative_items
within
declarative_parts is removed. This
means that things like
use_clauses and
variable_declarations
can be freely intermixed with things like bodies.
14.b
The syntax rule for proper_body
now allows a protected_body, and the rules
for elaboration checks now cover calls on protected operations.
Wording Changes from Ada 83
14.c
The syntax rule for later_declarative_item
is removed; the syntax rule for declarative_item
is new.
14.d
RM83 defines “elaborated” and “not
yet elaborated” for
declarative_items
here, and for other things in
3.1, “
Declarations”.
That's no longer necessary, since these terms are fully defined in
3.1.
14.e
In RM83, all uses of
declarative_part
are optional (except for the one in
block_statement
with a
declare) which is sort of strange, since a
declarative_part
can be empty, according to the syntax. That is,
declarative_parts
are sort of “doubly optional”. In Ada 95, these
declarative_parts
are always required (but can still be empty). To simplify description,
we go further and say (see
5.6, “
Block
Statements”) that a
block_statement
without an explicit
declarative_part is equivalent
to one with an empty one.
Wording Changes from Ada 95
14.f/2
{
8652/0009}
{
AI95-00137-01}
Corrigendum: Changed representation clauses
to aspect clauses to reflect that they are used for more than just representation.14.g/2
{
8652/0014}
{
AI95-00064-01}
Corrigendum: Clarified that the elaboration
check applies to all kinds of subprogram bodies.14.h/2
{
AI95-00420-01}
Defined “declaration list” to avoid
confusion for various rules. Other kinds of declaration list are defined
elsewhere.
Sponsored by Ada-Europe