3.1 Declarations
1
{entity [partial]}
The language defines several kinds of named
entities
that are declared by declarations.
{name
[partial]} The entity's
name is defined
by the declaration, usually by a
defining_identifier,
but sometimes by a
defining_character_literal
or
defining_operator_symbol.
2
There are several forms of declaration. A basic_declaration
is a form of declaration defined as follows.
Syntax
3/2
{
AI95-00348-01}
basic_declaration ::=
type_declaration |
subtype_declaration
|
object_declaration |
number_declaration
|
subprogram_declaration |
abstract_subprogram_declaration
|
null_procedure_declaration | package_declaration
| | renaming_declaration |
| exception_declaration
| | generic_declaration |
| generic_instantiation4
defining_identifier ::= identifier
Static Semantics
5
{Declaration}
[Glossary Entry]
A
declaration is a language
construct that associates a name with (a view of) an entity.
{explicit
declaration} {implicit
declaration} A declaration may appear
explicitly in the program text (an
explicit declaration), or may
be supposed to occur at a given place in the text as a consequence of
the semantics of another construct (an
implicit declaration).
5.a
Discussion: An implicit declaration generally
declares a predefined or inherited operation associated with the definition
of a type. This term is used primarily when allowing explicit declarations
to override implicit declarations, as part of a type declaration.
6/2
{
AI95-00318-02}
{declaration} Each
of the following is defined to be a declaration: any
basic_declaration;
an
enumeration_literal_specification; a
discriminant_specification;
a
component_declaration; a
loop_parameter_specification;
a
parameter_specification; a
subprogram_body;
an
entry_declaration; an
entry_index_specification;
a
choice_parameter_specification; a
generic_formal_parameter_declaration.
In addition, an extended_return_statement
is a declaration of its defining_identifier.
6.a
Discussion: This list (when basic_declaration
is expanded out) contains all syntactic categories that end in "_declaration"
or "_specification", except for program unit _specifications.
Moreover, it contains subprogram_body. A subprogram_body
is a declaration, whether or not it completes a previous declaration.
This is a bit strange, subprogram_body is
not part of the syntax of basic_declaration
or library_unit_declaration. A renaming-as-body
is considered a declaration. An accept_statement
is not considered a declaration. Completions are sometimes declarations,
and sometimes not.
7
All declarations contain a
definition for
a
view of an entity. A view consists of an identification of the
entity (the entity
of the view), plus view-specific characteristics
that affect the use of the entity through that view (such as mode of
access to an object, formal parameter names and defaults for a subprogram,
or visibility to components of a type). In most cases, a declaration
also contains the definition for the entity itself (a
renaming_declaration
is an example of a declaration that does not define a new entity, but
instead defines a view of an existing entity (see
8.5)).
7.a/2
Glossary entry: {View} A
view of an entity reveals some or all of the properties of the entity.
A single entity may have multiple views.(See
Definition.)
7.b
Discussion: Most declarations define
a view (of some entity) whose view-specific characteristics are unchanging
for the life of the view. However, subtypes are somewhat unusual in that
they inherit characteristics from whatever view of their type is currently
visible. Hence, a subtype is not a view of a type; it is more
of an indirect reference. By contrast, a private type provides a single,
unchanging (partial) view of its full type.
8
{view}
All declarations contain a
definition for
a
view of an entity. A view consists of an identification of the
entity (the entity
of the view), plus view-specific characteristics
that affect the use of the entity through that view (such as mode of
access to an object, formal parameter names and defaults for a subprogram,
or visibility to components of a type). In most cases, a declaration
also contains the definition for the entity itself (a
renaming_declaration
is an example of a declaration that does not define a new entity, but
instead defines a view of an existing entity (see
8.5)).
8.a/2
This paragraph
was deleted.Glossary entry: {Definition}
{view} All declarations contain a definition
for a view of an entity. A view consists of an identification
of the entity (the entity of the view), plus view-specific characteristics
that affect the use of the entity through that view (such as mode of
access to an object, formal parameter names and defaults for a subprogram,
or visibility to components of a type). In most cases, a declaration
also contains the definition for the entity itself (a renaming_declaration
is an example of a declaration that does not define a new entity, but
instead defines a view of an existing entity (see 8.5)).
9
{scope (informal
definition) [partial]} For each declaration,
the language rules define a certain region of text called the
scope
of the declaration (see
8.2). Most declarations
associate an
identifier with a declared entity.
Within its scope, and only there, there are places where it is possible
to use the
identifier to refer to the declaration,
the view it defines, and the associated entity; these places are defined
by the visibility rules (see
8.3).
{name
(of (a view of) an entity)} At such places
the
identifier is said to be a
name
of the entity (the
direct_name or
selector_name);
{denote (informal definition) [partial]}
the name is said to
denote the declaration,
the view, and the associated entity (see
8.6).
{declare} The
declaration is said to
declare the name, the view, and in most
cases, the entity itself.
10
As an alternative to an
identifier,
an enumeration literal can be declared with a
character_literal
as its name (see
3.5.1), and a function can
be declared with an
operator_symbol as its
name (see
6.1).
11
{defining name}
The syntax rules use the terms
defining_identifier,
defining_character_literal, and
defining_operator_symbol
for the defining occurrence of a name; these are collectively called
defining names.
{usage name}
The terms
direct_name
and
selector_name are used for usage occurrences
of
identifiers,
character_literals,
and
operator_symbols. These are collectively
called
usage names.
11.a
To be honest: The terms identifier,
character_literal, and operator_symbol
are used directly in contexts where the normal visibility rules do not
apply (such as the identifier that appears
after the end of a task_body). Analogous
conventions apply to the use of designator,
which is the collective term for identifier
and operator_symbol.
Dynamic Semantics
12
{execution [distributed]}
The process by which a construct achieves its run-time
effect is called
execution.
{elaboration
[distributed]} {evaluation
[distributed]} This process is also called
elaboration for declarations and
evaluation for expressions.
One of the terms execution, elaboration, or evaluation is defined by
this International Standard for each construct that has a run-time effect.
12.a
Glossary entry: {
Execution} The
process by which a construct achieves its run-time effect is called
execution.
{
elaboration}
{
evaluation}
Execution
of a declaration is also called
elaboration. Execution of an expression
is also called
evaluation.
12.b
To be honest: The term elaboration is
also used for the execution of certain constructs that are not declarations,
and the term evaluation is used for the execution of certain constructs
that are not expressions. For example, subtype_indications
are elaborated, and ranges are evaluated.
12.c
For bodies, execution and elaboration are both
explicitly defined. When we refer specifically to the execution of a
body, we mean the explicit definition of execution for that kind of body,
not its elaboration.
12.d
Discussion: Technically, "the execution
of a declaration" and "the elaboration of a declaration"
are synonymous. We use the term "elaboration" of a construct
when we know the construct is elaborable. When we are talking about more
arbitrary constructs, we use the term "execution". For example,
we use the term "erroneous execution", to refer to any erroneous
execution, including erroneous elaboration or evaluation.
12.e
When we explicitly define evaluation or elaboration
for a construct, we are implicitly defining execution of that construct.
12.f
We also use the term "execution" for
things like statements, which are executable,
but neither elaborable nor evaluable. We considered using the term "execution"
only for non-elaborable, non-evaluable constructs, and defining the term
"action" to mean what we have defined "execution"
to mean. We rejected this idea because we thought three terms that mean
the same thing was enough — four would be overkill. Thus, the term
"action" is used only informally in the standard (except where
it is defined as part of a larger term, such as "protected action").
12.f.1/2
Glossary entry: {Elaboration}
The process by which a declaration has its run-time effect is called
elaboration. Elaboration is one of the forms of execution.
12.f.2/2
Glossary entry: {Evaluation}
The process by which an expression has its run-time effect is called
evaluation. Evaluation is one of the forms of execution.
12.g
To be honest: {
elaborable}
A
construct is
elaborable if elaboration is defined for it. {
evaluable}
A construct is
evaluable if evaluation is
defined for it. {
executable}
A construct is
executable if execution is defined for it.
12.h
Discussion: Don't confuse “elaborable”
with “preelaborable” (defined in
10.2.1).
12.i
Evaluation of an evaluable construct produces
a result that is either a value, a denotation, or a range. The following
are evaluable: expression; name prefix;
range; entry_list_iterator;
and possibly discrete_range. The last one
is curious — RM83 uses the term “evaluation of a discrete_range,”
but never defines it. One might presume that the evaluation of a discrete_range
consists of the evaluation of the range or
the subtype_indication, depending on what
it is. But subtype_indications are not evaluated;
they are elaborated.
12.j
Intuitively, an executable construct
is one that has a defined run-time effect (which may be null). Since
execution includes elaboration and evaluation as special cases, all elaborable
and all evaluable constructs are also executable. Hence, most constructs
in Ada are executable. An important exception is that the constructs
inside a generic unit are not executable directly, but rather are used
as a template for (generally) executable constructs in instances of the
generic.
13
1
{declare}
At compile time, the declaration of an entity
declares
the entity.
{create} At
run time, the elaboration of the declaration
creates the entity.
13.a
Ramification: Syntactic categories for
declarations are named either entity_declaration
(if they include a trailing semicolon) or entity_specification
(if not).
13.b
{
entity}
The various
kinds of named entities that can be declared are as follows: an object
(including components and parameters), a named number, a type (the name
always refers to its first subtype), a subtype, a subprogram (including
enumeration literals and operators), a single entry, an entry family,
a package, a protected or task unit (which corresponds to either a type
or a single object), an exception, a generic unit, a label, and the name
of a statement.
13.c
Identifiers are also associated with names of
pragmas, arguments to pragmas, and with attributes, but these are not
user-definable.
Wording Changes from Ada 83
13.d
The syntax rule for defining_identifier
is new. It is used for the defining occurrence of an identifier.
Usage occurrences use the direct_name or selector_name
syntactic categories. Each occurrence of an identifier
(or simple_name), character_literal,
or operator_symbol in the Ada 83 syntax rules
is handled as follows in Ada 95:
13.e
- It
becomes a defining_identifier, defining_character_literal,
or defining_operator_symbol (or some syntactic
category composed of these), to indicate a defining occurrence;
13.f
- It becomes a direct_name,
in usage occurrences where the usage is required (in Section 8) to be
directly visible;
13.g
- It becomes a selector_name,
in usage occurrences where the usage is required (in Section 8) to be
visible but not necessarily directly visible;
13.h
- It remains an identifier,
character_literal, or operator_symbol,
in cases where the visibility rules do not apply (such as the designator
that appears after the end of a subprogram_body).
13.i
For declarations that come in “two parts”
(program unit declaration plus body, private or incomplete type plus
full type, deferred constant plus full constant), we consider both to
be defining occurrences. Thus, for example, the syntax for package_body
uses defining_identifier after the reserved
word body, as opposed to direct_name.
13.j
The defining occurrence of a statement name
is in its implicit declaration, not where it appears in the program text.
Considering the statement name itself to be the defining occurrence would
complicate the visibility rules.
13.k
The phrase “visible by selection”
is not used in Ada 95. It is subsumed by simply “visible”
and the Name Resolution Rules for selector_names.
13.l
(Note that in Ada 95, a declaration is visible
at all places where one could have used a selector_name,
not just at places where a selector_name was
actually used. Thus, the places where a declaration is directly visible
are a subset of the places where it is visible. See Section 8 for details.)
13.m
We use the term “declaration” to
cover _specifications that declare (views
of) objects, such as parameter_specifications.
In Ada 83, these are referred to as a “form of declaration,”
but it is not entirely clear that they are considered simply “declarations.”
13.n
RM83 contains an incomplete definition of "elaborated"
in this clause: it defines "elaborated" for declarations, declarative_parts,
declarative_items and compilation_units,
but "elaboration" is defined elsewhere for various other constructs.
To make matters worse, Ada 95 has a different set of elaborable constructs.
Instead of correcting the list, it is more maintainable to refer to the
term "elaborable," which is defined in a distributed manner.
13.o
RM83 uses the term “has no other effect”
to describe an elaboration that doesn't do anything except change the
state from not-yet-elaborated to elaborated. This was a confusing wording,
because the answer to “other than what?” was to be found
many pages away. In Ada 95, we change this wording to “has no effect”
(for things that truly do nothing at run time), and “has no effect
other than to establish that so-and-so can happen without failing the
Elaboration_Check” (for things where it matters).
13.p
We make it clearer that the term "execution"
covers elaboration and evaluation as special cases. This was implied
in RM83. For example, "erroneous execution" can include any
execution, and RM83-9.4(3) has, "The task designated by any other
task object depends on the master whose execution creates the task object;"
the elaboration of the master's declarative_part
is doing the task creation.
Wording Changes from Ada 95
13.q/2
{
AI95-00318-02}
Added extended_return_statement
to the list of declarations.13.r/2
Sponsored by Ada-Europe