Contents Index Search Previous Next
4.1 Names
1
[
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
2
name
::=
direct_name |
explicit_dereference
|
indexed_component |
slice
|
selected_component |
attribute_reference
|
type_conversion |
function_call
|
character_literal
3
direct_name
::= identifier |
operator_symbol
3.a
Discussion: character_literal
is no longer a direct_name. character_literals
are usable even when the corresponding enumeration_type_declaration
is not visible. See 4.2.
4
prefix
::= name |
implicit_dereference
5
explicit_dereference
::= name.
all
6
implicit_dereference
::= name
7
[Certain forms of name
(indexed_components, selected_components,
slices, and attributes)
include a prefix that is either
itself a name that denotes some
related entity, or an implicit_dereference
of an access value that designates some related entity.]
Name Resolution Rules
8
{dereference} {expected
type (dereference name) [partial]} The
name in a
dereference (either
an
implicit_dereference or an
explicit_dereference)
is expected to be of any access type.
Static Semantics
9
{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.
9.a
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.
9.b
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.
10
{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.
10.a
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
11
{evaluation (name) [partial]}
The evaluation of a
name
determines the entity denoted by the name. This evaluation has no other
effect for a
name that is a
direct_name
or a
character_literal.
12
{evaluation (name that has
a prefix) [partial]} [The evaluation of
a
name that has a
prefix
includes the evaluation of the
prefix.]
{evaluation (prefix) [partial]} The
evaluation of a
prefix consists
of the evaluation of the
name or
the
implicit_dereference. The
prefix
denotes the entity denoted by the
name
or the
implicit_dereference.
13
{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
14
Examples of
direct names:
15
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)
16
Examples of dereferences:
17
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
17.a
{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.
17.b/1
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 prefix.
See 4.6.
Wording Changes from Ada 83
17.c
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 the 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).
17.d
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.
17.e
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.
17.f
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.
17.g
We no longer use the term appropriate
for a type since we now describe the semantics of a prefix in terms
of implicit dereference.
Contents Index Search Previous Next Legal