[Home] [Prev] [Next] [Index]

4.1 Names

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
The name in a dereference (either an implicit_dereference or an explicit_dereference) is expected to be of any access type.

Static Semantics

9
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: 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
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
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
[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.

13
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

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

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.

4.1.1 Indexed Components

1
[An indexed_component denotes either a component of an array or an entry in a family of entries.]

Syntax

2
indexed_component ::= prefix(expression {, expression})

Name Resolution Rules

3
The prefix of an indexed_component with a given number of expressions shall resolve to denote an array (after any implicit dereference) with the corresponding number of index positions, or shall resolve to denote an entry family of a task or protected object (in which case there shall be only one expression).

4
The expected type for each expression is the corresponding index type.

Static Semantics

5
When the prefix denotes an array, the indexed_component denotes the component of the array with the specified index value(s). The nominal subtype of the indexed_component is the component subtype of the array type.

5.a
Ramification: In the case of an array whose components are aliased, and of an unconstrained discriminated subtype, the components are constrained even though their nominal subtype is unconstrained. (This is because all aliased discriminated objects are constrained. See 3.10.2.) In all other cases, an array component is constrained if and only if its nominal subtype is constrained.

6
When the prefix denotes an entry family, the indexed_component denotes the individual entry of the entry family with the specified index value.

Dynamic Semantics

7
For the evaluation of an indexed_component, the prefix and the expressions are evaluated in an arbitrary order.  The value of each expression is converted to the corresponding index type. A check is made that each index value belongs to the corresponding index range of the array or entry family denoted by the prefix. Constraint_Error is raised if this check fails.

Examples

8
Examples of indexed components:

9
My_Schedule(Sat)     --  a component of a one-dimensional array   (see 3.6.1)
Page(10)             --  a component of a one-dimensional array (see 3.6)
Board(M, J + 1)      --  a component of a two-dimensional array (see 3.6.1)
Page(10)(20)         --  a component of a component (see 3.6)
Request(Medium)      --  an entry in a family of entries (see 9.1)
Next_Frame(L)(M, N)  --  a component of a function call (see 6.1)

NOTES

10 1
Notes on the examples: Distinct notations are used for components of multidimensional arrays (such as  Board) and arrays of arrays (such as Page).  The components of an array of arrays are arrays and  can  therefore  be  indexed.   Thus  Page(10)(20) denotes  the 20th component of Page(10).  In the last example Next_Frame(L) is  a  function  call  returning  an  access  value  that   designates   a two-dimensional array.

4.1.2 Slices

1
[A slice denotes a one-dimensional array formed by a sequence of consecutive components of a one-dimensional array.  A slice of a variable is a variable; a slice of a constant is a constant;] a slice of a value is a value.

Syntax

2
slice ::= prefix(discrete_range)

Name Resolution Rules

3
The prefix of a slice shall resolve to denote a one-dimensional array (after any implicit dereference).

4
The expected type for the discrete_range of a slice is the index type of the array type.

Static Semantics

5
A slice denotes a one-dimensional array formed by the sequence of consecutive components of the array denoted by the prefix, corresponding to the range of values of the index given by the discrete_range.

6
The type of the slice is that of the prefix. Its bounds are those defined by the discrete_range.

Dynamic Semantics

7
For the evaluation of a slice, the prefix and the discrete_range are evaluated in an arbitrary order. If the slice is not a null slice (a slice where the discrete_range is a null range), then a check is made that the bounds of the discrete_range belong to the index range of the array denoted by the prefix. Constraint_Error is raised if this check fails.

NOTES

8 2
A slice is not permitted as the prefix of an Access attribute_reference, even if the components or the array as a whole are aliased. See 3.10.2.

8.a
Proof: Slices are not aliased, by 3.10, "Access Types".

8.b
Reason: This is to ease implementation of general-access-to-array. If slices were aliased, implementations would need to store array dope with the access values, which is not always desirable given access-to-incomplete types completed in a package body.

9 3
For  a  one-dimensional  array  A,  the  slice  A(N  .. N) denotes an array that has only one component; its type is the type of A.  On the other hand, A(N)  denotes  a component of the array A and has the corresponding component type.

Examples

10
Examples of slices:

11
  Stars(1 .. 15)        --  a slice of 15 characters                   (see 3.6.3)
  Page(10 .. 10 + Size) --  a slice of 1 + Size components (see 3.6)
  Page(L)(A .. B)       --  a slice of the array Page(L) (see 3.6)
  Stars(1 .. 0)         --  a null slice (see 3.6.3)
  My_Schedule(Weekday)  --  bounds given by subtype (see 3.6.1 and 3.5.1)
  Stars(5 .. 15)(K)     --  same as Stars(K) (see 3.6.3)
                        --  provided that K is in 5 .. 15

4.1.3 Selected Components

1
[Selected_components are used to denote components (including discriminants), entries, entry families, and protected subprograms; they are also used as expanded names as described below.]

Syntax

2
selected_component ::= prefix . selector_name

3
selector_name ::= identifier | character_literal | operator_symbol

Name Resolution Rules

4
A selected_component is called an expanded name if, according to the visibility rules, at least one possible interpretation of its prefix denotes a package or an enclosing named construct (directly, not through a subprogram_renaming_declaration or generic_renaming_declaration).

4.a
Discussion:  See AI-00187.

5
A selected_component that is not an expanded name shall resolve to denote one of the following:

5.a
Ramification: If the prefix of a selected_component denotes an enclosing named construct, then the selected_component is interpreted only as an expanded name, even if the named construct is a function that could be called without parameters.

6 ·
A component [(including a discriminant)]:

7
The prefix shall resolve to denote an object or value of some non-array composite type (after any implicit dereference). The selector_name shall resolve to denote a discriminant_specification of the type, or, unless the type is a protected type, a component_declaration of the type.  The selected_component denotes the corresponding component of the object or value.

7.a
Reason: The components of a protected object cannot be named except by an expanded name, even from within the corresponding protected body. The protected body may not reference the the private components of some arbitrary object of the protected type; the protected body may reference components of the current instance only (by an expanded name or a direct_name).

7.b
Ramification: Only the discriminants and components visible at the place of the selected_component can be selected, since a selector_name can only denote declarations that are visible (see 8.3).

8 ·
A single entry, an entry family, or a protected subprogram:

9
The prefix shall resolve to denote an object or value of some task or protected type (after any implicit dereference). The selector_name shall resolve to denote an entry_declaration or subprogram_declaration occurring (implicitly or explicitly) within the visible part of that type. The selected_component denotes the corresponding entry, entry family, or protected subprogram.

9.a
Reason: This explicitly says "visible part" because even though the body has visibility on the private part, it cannot call the private operations of some arbitrary object of the task or protected type, only those of the current instance (and expanded name notation has to be used for that).

10
An expanded name shall resolve to denote a declaration that occurs immediately within a named declarative region, as follows:

11 ·
The prefix shall resolve to denote either a package [(including the current instance of a generic package, or a rename of a package)], or an enclosing named construct.

12 ·
The selector_name shall resolve to denote a declaration that occurs immediately within the declarative region of the package or enclosing construct [(the declaration shall be visible at the place of the expanded name - see 8.3)]. The expanded name denotes that declaration.

12.a
Ramification: Hence, a library unit or subunit can use an expanded name to refer to the declarations within the private part of its parent unit, as well as to other children that have been mentioned in with_clauses.

13 ·
If the prefix does not denote a package, then it shall be a direct_name or an expanded name, and it shall resolve to denote a program unit (other than a package), the current instance of a type, a block_statement, a loop_statement, or an accept_statement (in the case of an accept_statement or entry_body, no family index is allowed); the expanded name shall occur within the declarative region of this construct. Further, if this construct is a callable construct and the prefix denotes more than one such enclosing callable construct, then the expanded name is ambiguous, independently of the selector_name.

Dynamic Semantics

14
The evaluation of a selected_component includes the evaluation of the prefix.

15
For a selected_component that denotes a component of a variant, a check is made that the values of the discriminants are such that the value or object denoted by the prefix has this component. The exception Constraint_Error is raised if this check fails.

Examples

16
Examples of selected components:

17
  Tomorrow.Month     --  a record component                             (see 3.8)
  Next_Car.Owner     --  a record component (see 3.10.1)
  Next_Car.Owner.Age --  a record component (see 3.10.1)
                     --  the previous two lines involve implicit dereferences
  Writer.Unit        --  a record component (a discriminant) (see 3.8.1)
  Min_Cell(H).Value  --  a record component of the result (see 6.1)
                     --  of the function call Min_Cell(H)
  Control.Seize      --  an entry of a protected object (see 9.4)
  Pool(K).Write      --  an entry of the task Pool(K) (see 9.4)

18
Examples of expanded names:

19
  Key_Manager."<"      --  an operator of the visible part of a package (see 7.3.1)
  Dot_Product.Sum      --  a variable declared in a function body (see 6.1)
  Buffer.Pool          --  a variable declared in a protected unit (see 9.11)
  Buffer.Read          --  an entry of a protected unit (see 9.11)
  Swap.Temp            --  a variable declared in a block statement (see 5.6)
  Standard.Boolean     --  the name of a predefined type (see A.1)

Extensions to Ada 83

19.a
We now allow an expanded name to use a prefix that denotes a rename of a package, even if the selector is for an entity local to the body or private part of the package, so long as the entity is visible at the place of the reference.  This eliminates a preexisting anomaly where references in a package body may refer to declarations of its visible part but not those of its private part or body when the prefix is a rename of the package.

Wording Changes From Ada 83

19.b
The syntax rule for selector_name is new.  It is used in places where visibility, but not necessarily direct visibility, is required. See 4.1, "Names" for more information.

19.c
The description of dereferencing an access type has been moved to 4.1, "Names"; name.all is no longer considered a selected_component.

19.d
The rules have been restated to be consistent with our new terminology, to accommodate class-wide types, etc.

4.1.4 Attributes

1
[An attribute is a characteristic of an entity that can be queried via an attribute_reference or a range_attribute_reference.]

Syntax

2
attribute_reference ::= prefix'attribute_designator

3
attribute_designator ::=
    identifier[(static_expression)]
  | Access | Delta | Digits

4
range_attribute_reference ::= prefix'range_attribute_designator

5
range_attribute_designator ::= Range[(static_expression)]

Name Resolution Rules

6
In an attribute_reference, if the attribute_designator is for an attribute defined for (at least some) objects of an access type, then the prefix is never interpreted as an implicit_dereference; otherwise (and for all range_attribute_references), if the type of the name within the prefix is of an access type, the prefix is interpreted as an implicit_dereference. Similarly, if the attribute_designator is for an attribute defined for (at least some) functions, then the prefix is never interpreted as a parameterless function_call; otherwise (and for all range_attribute_references), if the prefix consists of a name that denotes a function, it is interpreted as a parameterless function_call.

6.a
Discussion:  The first part of this rule is essentially a "preference" against implicit dereference, so that it is possible to ask for, say, 'Size of an access object, without automatically getting the size of the object designated by the access object. This rule applies to 'Access, 'Unchecked_Access, 'Size, and 'Address, and any other attributes that are defined for at least some access objects.

6.b
The second part of this rule implies that, for a parameterless function F, F'Address is the address of F, whereas F'Size is the size of the anonymous constant returned by F.

6.c
We normally talk in terms of expected type or profile for name resolution rules, but we don't do this for attributes because certain attributes are legal independent of the type or the profile of the prefix.

7
The expression, if any, in an attribute_designator or range_attribute_designator is expected to be of any integer type.

Legality Rules

8
The expression, if any, in an attribute_designator or range_attribute_designator shall be static.

Static Semantics

9
An attribute_reference denotes a value, an object, a subprogram, or some other kind of program entity.

9.a
Ramification: The attributes defined by the language are summarized in Annex K. Implementations can define additional attributes.

10
[A range_attribute_reference X'Range(N) is equivalent to the range X'First(N) .. X'Last(N), except that the prefix is only evaluated once. Similarly, X'Range is equivalent to X'First .. X'Last, except that the prefix is only evaluated once.]

Dynamic Semantics

11
The evaluation of an attribute_reference (or range_attribute_reference) consists of the evaluation of the prefix.

Implementation Permissions

12
An implementation may provide implementation-defined attributes; the identifier for an implementation-defined attribute shall differ from those of the language-defined attributes.

12.a
Implementation defined:  Implementation-defined attributes.

12.b
Ramification: They cannot be reserved words because reserved words are not legal identifiers.

12.c
The semantics of implementation-defined attributes, and any associated rules, are, of course, implementation defined. For example, the implementation defines whether a given implementation-defined attribute can be used in a static expression.

NOTES

13 4
Attributes are defined throughout this International Standard, and are summarized in Annex K.

14 5
In general, the name in a prefix of an attribute_reference (or a range_attribute_reference) has to be resolved without using any context. However, in the case of the Access attribute, the expected type for the prefix has to be a single access type, and if it is an access-to-subprogram type (see 3.10.2) then the resolution of the name can use the fact that the profile of the callable entity denoted by the prefix has to be type conformant with the designated profile of the access type.

14.a
Proof: In the general case, there is no "expected type" for the prefix of an attribute_reference. In the special case of 'Access, there is an "expected profile" for the prefix.

14.b
Reason:'Access is a special case, because without it, it would be very difficult to take 'Access of an overloaded subprogram.

Examples

15
Examples of attributes:

16
Color'First        -- minimum value of the enumeration type Color   (see 3.5.1)
Rainbow'Base'First -- same as Color'First (see 3.5.1)
Real'Digits        -- precision of the type Real (see 3.5.7)
Board'Last(2)      -- upper bound of the second dimension of Board (see 3.6.1)
Board'Range(1)     -- index range of the first dimension of Board (see 3.6.1)
Pool(K)'Terminated -- True if task Pool(K) is terminated (see 9.1)
Date'Size          -- number of bits for records of type Date (see 3.8)
Message'Address    -- address of the record variable Message (see 3.7.1)

Extensions to Ada 83

16.a
We now uniformly treat X'Range as X'First..X'Last, allowing its use with scalar subtypes.

16.b
We allow any integer type in the static_expression of an attribute designator, not just a value of universal_integer.  The preference rules ensure upward compatibility.

Wording Changes From Ada 83

16.c
We use the syntactic category attribute_reference rather than simply "attribute" to avoid confusing the name of something with the thing itself.

16.d
The syntax rule for attribute_reference now uses identifier instead of simple_name, because attribute identifiers are not required to follow the normal visibility rules.

16.e
We now separate attribute_reference from range_attribute_reference, and enumerate the reserved words that are legal attribute or range attribute designators. We do this because identifier no longer includes reserved words.

16.f
The Ada 9X name resolution rules are a bit more explicit than in Ada 83. The Ada 83 rule said that the "meaning of the prefix of an attribute must be determinable independently of the attribute designator and independently of the fact that it is the prefix of an attribute."  That isn't quite right since the meaning even in Ada 83 embodies whether or not the prefix is interpreted as a parameterless function call, and in Ada 9X, it also embodies whether or not the prefix is interpreted as an implicit_dereference.  So the attribute designator does make a difference - just not much.

16.g
Note however that if the attribute designator is Access, it makes a big difference in the interpretation of the prefix (see 3.10.2).



[Home] [Prev] [Next] [Index]

documentation@rational.com
Copyright © 1993-1998, Rational Software Corporation.   All rights reserved.