3.1 Declarations
Discussion: {
AI12-0373-1}
Some entities are always anonymous. For instance, a type is never named
(the name represents the first subtype). We don't mention those here
as this paragraph is about
named entities.
There are several forms of declaration. A
basic_declaration
is a form of declaration defined as follows.
Syntax
Static Semantics
A
declaration is a language
construct that associates a name with (a view of) an entity.
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).
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.
Term entry: declaration —
language construct that associates a name with (a view of) an entity
Note: A declaration can appear explicitly in the program text (an explicit
declaration), or can be supposed to occur at a given place in the text
as a consequence of the semantics of another construct (an implicit declaration).
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)).
Term entry: view of an entity
— representation of an entity that reveals some or all of the properties
of the entity
Note: A single entity can have multiple views.
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.
{
AI05-0080-1}
When it is clear from context, the term
object is used in place
of
view of an object. Similarly, the terms
type and
subtype
are used in place of
view of a type and
view of a subtype,
respectively.
Discussion: Rules interpreted at compile
time generally refer to views of entities, rather than the entities themselves.
This is necessary to preserve privacy; characteristics that are not visible
should not be used in compile-time rules. Thus, Static Semantics and
Legality Rules generally implicitly have “view of”. Legality
Rules that need to look into the private part are the exception to this
interpretation.
On the other hand, run-time rules can work either
way, so “view of” should not be assumed in Dynamic Semantics
rules.
{
AI12-0191-1}
For example, a reference to the components of an object in a rule that
is interpreted at compile time would not apply to components that are
not visible. On the other hand, a reference to the components of an object
in a dynamic semantics rule would apply to all components of the object,
visible or not, including (for tagged objects) components which are not
components of the nominal type of the object (see
3.9.1).
Other terms, such as “subcomponent” and “part”,
are interpreted analogously.
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).
At such places the
identifier
is said to be a
name of the entity (the
direct_name
or
selector_name);
the name is said to
denote the declaration,
the view, and the associated entity (see
8.6).
The declaration is said to
declare the name,
the view, and in most cases, the entity itself.
Dynamic Semantics
The process by which a construct
achieves its run-time effect is called
execution.
This
process is also called
elaboration for declarations and
evaluation
for expressions. One of the terms execution, elaboration, or evaluation
is defined by this Reference Manual for each construct that has a run-time
effect.
Term entry: execution —
process by which a construct achieves its run-time effect
Note: Execution of a declaration is also called elaboration. Execution
of an expression is also called evaluation.
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.
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.
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.
When we explicitly define evaluation or elaboration
for a construct, we are implicitly defining execution of that construct.
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 nonelaborable, nonevaluable
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").
Term entry: elaboration —
process by which a declaration achieves its run-time effect
Note: Elaboration is one of the forms of execution.
Term entry: evaluation —
process by which an expression achieves its run-time effect
Note: Evaluation is one of the forms of execution.
To be honest: A construct
is
elaborable if elaboration is defined for it.
A
construct is
evaluable if evaluation is defined for it.
A
construct is
executable if execution is defined for it.
Discussion: Don't confuse “elaborable”
with “preelaborable” (defined in
10.2.1).
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.
NOTE
At compile
time, the declaration of an entity
declares the entity.
At
run time, the elaboration of the declaration
creates the entity.
Ramification: Syntactic categories for
declarations are named either entity_declaration
(if they include a trailing semicolon) or entity_specification
(if not).
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.
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
It becomes a
direct_name,
in usage occurrences where the usage is required (in Clause
8
to be directly visible;
It becomes a
selector_name,
in usage occurrences where the usage is required (in Clause
8)
to be visible but not necessarily directly visible;
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.
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.
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.
{
AI05-0299-1}
(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 Clause
8
for details.)
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”.
{
AI05-0299-1}
RM83 contains an incomplete definition of "elaborated" in this
subclause: 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.
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).
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
Wording Changes from Ada 2005
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe