Ada Resource Association
News and resources for the Ada programming language
Annotated Ada Reference ManualLegal Information
Contents   Index   References   Search   Previous   Next 

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


{AI05-0003-1} {AI05-0139-2} name ::= 
     direct_name | explicit_dereference
   | indexed_component | slice
   | selected_component | attribute_reference
   | type_conversion | function_call
   | character_literal | qualified_expression
   | generalized_reference | generalized_indexing
direct_name ::= identifier | operator_symbol
Discussion: {AI95-00114-01} character_literal is no longer a direct_name. character_literals are usable even when the corresponding enumeration type declaration enumeration_type_declaration is not visible. See 4.2
prefix ::= name | implicit_dereference
explicit_dereference ::= name.all
implicit_dereference ::= name
{AI05-0004-1} [Certain forms of name (indexed_components, selected_components, slices, and attribute_references 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

The name in a dereference (either an implicit_dereference or an explicit_dereference) is expected to be of any access type. 

Static Semantics

{AI05-0008-1} 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. If the designated subtype has unconstrained discriminants, the (actual) subtype of the view is constrained by the values of the discriminants of the designated object, except when there is a partial view of the type of the designated subtype that does not have discriminants, in which case the dereference is not constrained by its discriminant values. 
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: 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. 
Reason: {AI05-0008-1} The last sentence was not present in Ada 95; it is necessary in Ada 2005 because general access types can designate unconstrained objects, which was not possible in Ada 95. Thus, the rules that had this effect in Ada 95 (the object being constrained by its initial value) don't work in Ada 2005 and we have to say this explicitly.
{AI05-0008-1} The “except” part of the last sentence prevents privacy “breaking”, so that if a private type has discriminants only in the full view, they don't interfere with freely interassigning values between objects of the type, even when the objects live in the heap. 
Implementation Note: {AI05-0008-1} 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.
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

 {AI95-00415-01} The evaluation of a name determines the entity denoted by the name name. This evaluation has no other effect for a name that is a direct_name or a character_literal.
[The evaluation of a name that has a prefix includes the evaluation of the prefix.] 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.
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. A check is made that the value of the name is not the null access value. Constraint_Error is raised if this check fails. The dereference denotes the object or subprogram designated by the value of the name.


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

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

Extensions to Ada 2005

{AI05-0003-1} A qualified_expression is now a name denoting a constant view; this allows them to be used as a prefix and to be renamed as an object. They are often used to remove ambiguity from function calls, and there may be no other way to do that. Interestingly, a type_conversion of a qualified_expression is already legal in these contexts, so this change mainly reduces clutter by eliminating an otherwise unneeded type_conversion from some expressions. 

Wording Changes from Ada 2005

{AI05-0008-1} Correction: Added a missing rule so that most dereferences are assumed constrained (without determining whether the designated object is). This is just confirming the Ada 95 rules; Ada 2005 failed to ensure that this property was unchanged.
{AI05-0139-2} {AI05-0299-1} Added generalized_reference and generalized_indexing as types of name; these are documented as extensions in the appropriate subclauses.

Contents   Index   References   Search   Previous   Next 
Ada-Europe Ada 2005 and 2012 Editions sponsored in part by Ada-Europe