4.1 Names
[
Names
can denote declared entities, whether declared explicitly or implicitly
(see
3.1).
Names
can also denote objects or subprograms designated by access values; the
results of
type_conversions
or
function_calls;
subcomponents and slices of objects and values; protected subprograms,
single entries, entry families, and entries in families of entries. Finally,
names can
denote attributes of any of the foregoing.]
Syntax
explicit_dereference ::= name.
all
implicit_dereference ::= name
Name Resolution Rules
Static Semantics
{nominal subtype
(associated with a dereference) [partial]} If
the type of the
name
in a dereference is some access-to-object type
T, then the dereference
denotes a view of an object, the
nominal subtype of the view being
the designated subtype of
T.
Ramification: If the value of the
name
is the result of an access type conversion, the dereference denotes a
view created as part of the conversion. The nominal subtype of the view
is not necessarily the same as that used to create the designated object.
See
4.6.
To be honest: {
nominal subtype (of
a name) [partial]}
We sometimes refer to the
nominal subtype of a particular kind of
name
rather than the nominal subtype of the view denoted by the
name
(presuming the
name
denotes a view of an object). These two uses of nominal subtype are intended
to mean the same thing.
{
AI95-00363-01}
If an
allocator
for the access-to-object type
T is one that creates objects that
are constrained by their initial value (see
4.8),
the subtype of the dereference is constrained even if the designated
subtype of
T is not. We don't want the effect of the dereference
to depend on the designated object. This matters because general access-to-unconstrained
can designate both allocated objects (which are constrained at birth)
and aliased stack objects (which aren't necessarily constrained). This
is a wording bug that was discovered after the completion of Amendment
1 when it was too late to fix it; we expect that it will be corrected
by an early Ada 2005 AI.
Implementation Note: {
AI95-00363-01}
Since we don't depend on whether the designated object is constrained,
it is not necessary to include a constrained bit in every object that
could be designated by a general access type.
{profile (associated
with a dereference) [partial]} If the
type of the
name
in a dereference is some access-to-subprogram type
S, then the
dereference denotes a view of a subprogram, the
profile of the
view being the designated profile of
S.
Ramification: This means that the formal
parameter names and default expressions to be used in a call whose
name
or
prefix
is a dereference are those of the designated profile, which need not
be the same as those of the subprogram designated by the access value,
since 'Access requires only subtype conformance, not full conformance.
Dynamic Semantics
{evaluation (dereference)
[partial]} The evaluation of a dereference
consists of the evaluation of the
name
and the determination of the object or subprogram that is designated
by the value of the
name.
{Access_Check [partial]} {check,
language-defined (Access_Check)} A check
is made that the value of the
name
is not the null access value.
{Constraint_Error
(raised by failure of run-time check)} Constraint_Error
is raised if this check fails. The dereference denotes the object or
subprogram designated by the value of the
name.
Examples
Examples of direct
names:
Pi
-- the direct name of a number (see
3.3.2)
Limit
-- the direct name of a constant (see
3.3.1)
Count
-- the direct name of a scalar variable (see
3.3.1)
Board
-- the direct name of an array variable (see
3.6.1)
Matrix
-- the direct name of a type (see
3.6)
Random
-- the direct name of a function (see
6.1)
Error
-- the direct name of an exception (see
11.1)
Examples of dereferences:
Next_Car.
all --
explicit dereference denoting the object designated by
--
the access variable Next_Car (see 3.10.1)
Next_Car.Owner --
selected component with implicit dereference;
--
same as Next_Car.all.Owner
Extensions to Ada 83
{
extensions to Ada 83}
Type
conversions and function calls are now considered names that denote the
result of the operation. In the case of a type conversion used as an
actual parameter or that is of a tagged type, the type conversion is
considered a variable if the operand is a variable. This simplifies the
description of "parameters of the form of a type conversion"
as well as better supporting an important OOP paradigm that requires
the combination of a conversion from a class-wide type to some specific
type followed immediately by component selection. Function calls are
considered names so that a type conversion of a function call and the
function call itself are treated equivalently in the grammar. A function
call is considered the name of a constant, and can be used anywhere such
a name is permitted. See
6.5.
Type conversions of a tagged type are permitted
anywhere their operand is permitted. That is, if the operand is a variable,
then the type conversion can appear on the left-hand side of an
assignment_statement.
If the operand is an object, then the type conversion can appear in an
object renaming or as a
prefix.
See
4.6.
Wording Changes from Ada 83
{
AI95-00114-01}
Everything of the general syntactic form
name(...)
is now syntactically a
name.
In any realistic parser, this would be a necessity since distinguishing
among the various
name(...)
constructs inevitably requires name resolution. In cases where the construct
yields a value rather than an object, the name denotes a value rather
than an object. Names already denote values in Ada 83 with named numbers,
components of the result of a function call, etc. This is partly just
a wording change, and partly an extension of functionality (see Extensions
heading above).
The syntax rule for
direct_name
is new. It is used in places where direct visibility is required. It's
kind of like Ada 83's
simple_name, but
simple_name
applied to both direct visibility and visibility by selection, and furthermore,
it didn't work right for
operator_symbols.
The syntax rule for
simple_name is removed,
since its use is covered by a combination of
direct_name
and
selector_name.
The syntactic categories
direct_name
and
selector_name
are similar; it's mainly the visibility rules that distinguish the two.
The introduction of
direct_name
requires the insertion of one new explicit textual rule: to forbid
statement_identifiers
from being
operator_symbols.
This is the only case where the explicit rule is needed, because this
is the only case where the declaration of the entity is implicit. For
example, there is no need to syntactically forbid (say) “X: "Rem";”,
because it is impossible to declare a type whose name is an
operator_symbol
in the first place.
The syntax rules for
explicit_dereference
and
implicit_dereference
are new; this makes other rules simpler, since dereferencing an access
value has substantially different semantics from
selected_components.
We also use
name
instead of
prefix
in the
explicit_dereference
rule since that seems clearer. Note that these rules rely on the fact
that function calls are now names, so we don't need to use prefix to
allow functions calls in front of .
all.
Discussion: Actually, it would be reasonable
to allow any
primary
in front of .
all, since only the value is needed, but that would
be a bit radical.
We no longer use the term appropriate for
a type since we now describe the semantics of a prefix in terms of
implicit dereference.