3.11 Declarative Parts

[A declarative_part contains declarative_items (possibly none).]

Syntax

declarative_part ::= {declarative_item}

declarative_item ::=
basic_declarative_item | body

4/1

{8652/0009} basic_declarative_item ::=
basic_declaration | aspect_clause ~~representation_clause~~ | use_clause

body ::= proper_body | body_stub

proper_body ::=
subprogram_body | package_body | task_body | protected_body

Dynamic Semantics

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

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

{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} 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} A subprogram can be completed by a renames-as-body, and we need to make an elaboration check on such a body, so we use ``body'' rather than subprogram_body above.

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.

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.

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.

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

Contents Index Search Previous Next Legal