

                         Section 8: Visibility Rules


1     The rules defining the scope of declarations and the rules defining
which identifiers, character_literals, and operator_symbols are visible at (or
from) various places in the text of the program are described in this section.
The formulation of these rules uses the notion of a declarative region.

2     As explained in Section 3, a declaration declares a view of an entity
and associates a defining name with that view. The view comprises an
identification of the viewed entity, and possibly additional properties. A
usage name denotes a declaration. It also denotes the view declared by that
declaration, and denotes the entity of that view. Thus, two different usage
names might denote two different views of the same entity; in this case they
denote the same entity.


8.1 Declarative Region



                              Static Semantics

1     For each of the following constructs, there is a portion of the program
text called its declarative region, within which nested declarations can
occur:

2     any declaration, other than that of an enumeration type, that is not a
      completion of a previous declaration;

3     a block_statement;

4     a loop_statement;

5     an accept_statement;

6     an exception_handler.

7     The declarative region includes the text of the construct together with
additional text determined (recursively), as follows:

8     If a declaration is included, so is its completion, if any.

9     If the declaration of a library unit (including Standard - see 10.1.1)
      is included, so are the declarations of any child units (and their
      completions, by the previous rule). The child declarations occur after
      the declaration.

10    If a body_stub is included, so is the corresponding subunit.

11    If a type_declaration is included, then so is a corresponding
      record_representation_clause, if any.

12    The declarative region of a declaration is also called the declarative
region of any view or entity declared by the declaration.

13    A declaration occurs immediately within a declarative region if this
region is the innermost declarative region that encloses the declaration (the
immediately enclosing declarative region), not counting the declarative region
(if any) associated with the declaration itself.

14    A declaration is local to a declarative region if the declaration occurs
immediately within the declarative region. An entity is local to a declarative
region if the entity is declared by a declaration that is local to the
declarative region.

15    A declaration is global to a declarative region if the declaration
occurs immediately within another declarative region that encloses the
declarative region. An entity is global to a declarative region if the entity
is declared by a declaration that is global to the declarative region.

      NOTES

16    1  The children of a parent library unit are inside the parent's
      declarative region, even though they do not occur inside the parent's
      declaration or body. This implies that one can use (for example) "P.Q"
      to refer to a child of P whose defining name is Q, and that after "use
      P;" Q can refer (directly) to that child.

17    2  As explained above and in 10.1.1, ``
      Compilation Units - Library Units'', all library units are descendants
      of Standard, and so are contained in the declarative region of Standard.
      They are not inside the declaration or body of Standard, but they are
      inside its declarative region.

18    3  For a declarative region that comes in multiple parts, the text of
      the declarative region does not contain any text that might appear
      between the parts. Thus, when a portion of a declarative region is said
      to extend from one place to another in the declarative region, the
      portion does not contain any text that might appear between the parts of
      the declarative region.


8.2 Scope of Declarations


1     For each declaration, the language rules define a certain portion of the
program text called the scope of the declaration. The scope of a declaration
is also called the scope of any view or entity declared by the declaration.
Within the scope of an entity, and only there, there are places where it is
legal to refer to the declared entity. These places are defined by the rules
of visibility and overloading.


                              Static Semantics

2     The immediate scope of a declaration is a portion of the declarative
region immediately enclosing the declaration. The immediate scope starts at
the beginning of the declaration, except in the case of an overloadable
declaration, in which case the immediate scope starts just after the place
where the profile of the callable entity is determined (which is at the end of
the _specification for the callable entity, or at the end of the
generic_instantiation if an instance). The immediate scope extends to the end
of the declarative region, with the following exceptions:

3     The immediate scope of a library_item includes only its semantic
      dependents.

4     The immediate scope of a declaration in the private part of a library
      unit does not include the visible part of any public descendant of that
      library unit.

5     The visible part of (a view of) an entity is a portion of the text of
its declaration containing declarations that are visible from outside. The
private part of (a view of) an entity that has a visible part contains all
declarations within the declaration of (the view of) the entity, except those
in the visible part; these are not visible from outside. Visible and private
parts are defined only for these kinds of entities: callable entities, other
program units, and composite types.

6     The visible part of a view of a callable entity is its profile.

7     The visible part of a composite type other than a task or protected type
      consists of the declarations of all components declared (explicitly or
      implicitly) within the type_declaration.

8     The visible part of a generic unit includes the generic_formal_part. For
      a generic package, it also includes the first list of
      basic_declarative_items of the package_specification. For a generic
      subprogram, it also includes the profile.

9     The visible part of a package, task unit, or protected unit consists of
      declarations in the program unit's declaration other than those
      following the reserved word private, if any; see 7.1 and 12.7 for
      packages, 9.1 for task units, and 9.4 for protected units.

10    The scope of a declaration always contains the immediate scope of the
declaration. In addition, for a given declaration that occurs immediately
within the visible part of an outer declaration, or is a public child of an
outer declaration, the scope of the given declaration extends to the end of
the scope of the outer declaration, except that the scope of a library_item
includes only its semantic dependents.

11    The immediate scope of a declaration is also the immediate scope of the
entity or view declared by the declaration. Similarly, the scope of a
declaration is also the scope of the entity or view declared by the
declaration.

      NOTES

12    4  There are notations for denoting visible declarations that are not
      directly visible. For example, parameter_specifications are in the
      visible part of a subprogram_declaration so that they can be used in
      named-notation calls appearing outside the called subprogram. For
      another example, declarations of the visible part of a package can be
      denoted by expanded names appearing outside the package, and can be made
      directly visible by a use_clause.


8.3 Visibility


1     The visibility rules, given below, determine which declarations are
visible and directly visible at each place within a program. The visibility
rules apply to both explicit and implicit declarations.


                              Static Semantics

2     A declaration is defined to be directly visible at places where a name
consisting of only an identifier or operator_symbol is sufficient to denote
the declaration; that is, no selected_component notation or special context
(such as preceding => in a named association) is necessary to denote the
declaration. A declaration is defined to be visible wherever it is directly
visible, as well as at other places where some name (such as a
selected_component) can denote the declaration.

3     The syntactic category direct_name is used to indicate contexts where
direct visibility is required. The syntactic category selector_name is used to
indicate contexts where visibility, but not direct visibility, is required.

4     There are two kinds of direct visibility: immediate visibility and
use-visibility. A declaration is immediately visible at a place if it is
directly visible because the place is within its immediate scope. A
declaration is use-visible if it is directly visible because of a use_clause
(see 8.4). Both conditions can apply.

5     A declaration can be hidden, either from direct visibility, or from all
visibility, within certain parts of its scope. Where hidden from all
visibility, it is not visible at all (neither using a direct_name nor a
selector_name). Where hidden from direct visibility, only direct visibility is
lost; visibility using a selector_name is still possible.

6     Two or more declarations are overloaded if they all have the same
defining name and there is a place where they are all directly visible.

7     The declarations of callable entities (including enumeration literals)
are overloadable, meaning that overloading is allowed for them.

8     Two declarations are homographs if they have the same defining name,
and, if both are overloadable, their profiles are type conformant. An inner
declaration hides any outer homograph from direct visibility.

9/1   Two homographs are not generally allowed immediately within the same
declarative region unless one overrides the other (see Legality Rules below).
The only declarations that are overridable are the implicit declarations for
predefined operators and inherited primitive subprograms. A declaration
overrides another homograph that occurs immediately within the same
declarative region in the following cases:

10/1  A declaration that is not overridable overrides one that is overridable,
      regardless of which declaration occurs first;

11    The implicit declaration of an inherited operator overrides that of a
      predefined operator;

12    An implicit declaration of an inherited subprogram overrides a previous
      implicit declaration of an inherited subprogram.

13    For an implicit declaration of a primitive subprogram in a generic unit,
      there is a copy of this declaration in an instance. However, a whole new
      set of primitive subprograms is implicitly declared for each type
      declared within the visible part of the instance. These new declarations
      occur immediately after the type declaration, and override the copied
      ones. The copied ones can be called only from within the instance; the
      new ones can be called only from outside the instance, although for
      tagged types, the body of a new one can be executed by a call to an old
      one.

14    A declaration is visible within its scope, except where hidden from all
visibility, as follows:

15    An overridden declaration is hidden from all visibility within the scope
      of the overriding declaration.

16    A declaration is hidden from all visibility until the end of the
      declaration, except:

    17    For a record type or record extension, the declaration is hidden
          from all visibility only until the reserved word record;

    18    For a package_declaration, task declaration, protected declaration,
          generic_package_declaration, or subprogram_body, the declaration is
          hidden from all visibility only until the reserved word is of the
          declaration.

19    If the completion of a declaration is a declaration, then within the
      scope of the completion, the first declaration is hidden from all
      visibility. Similarly, a discriminant_specification or parameter_-
      specification is hidden within the scope of a corresponding discriminant_-
      specification or parameter_specification of a corresponding completion,
      or of a corresponding accept_statement.

20    The declaration of a library unit (including a
      library_unit_renaming_declaration) is hidden from all visibility except
      at places that are within its declarative region or within the scope of
      a with_clause that mentions it. For each declaration or renaming of a
      generic unit as a child of some parent generic package, there is a
      corresponding declaration nested immediately within each instance of the
      parent. Such a nested declaration is hidden from all visibility except
      at places that are within the scope of a with_clause that mentions the
      child.

21    A declaration with a defining_identifier or defining_operator_symbol is
immediately visible (and hence directly visible) within its immediate scope
except where hidden from direct visibility, as follows:

22    A declaration is hidden from direct visibility within the immediate
      scope of a homograph of the declaration, if the homograph occurs within
      an inner declarative region;

23    A declaration is also hidden from direct visibility where hidden from
      all visibility.


                            Name Resolution Rules

24    A direct_name shall resolve to denote a directly visible declaration
whose defining name is the same as the direct_name. A selector_name shall
resolve to denote a visible declaration whose defining name is the same as the
selector_name.

25    These rules on visibility and direct visibility do not apply in a
context_clause, a parent_unit_name, or a pragma that appears at the place of a
compilation_unit. For those contexts, see the rules in 10.1.6, ``
Environment-Level Visibility Rules''.


                               Legality Rules

26/1  A non-overridable declaration is illegal if there is a homograph
occurring immediately within the same declarative region that is visible at
the place of the declaration, and is not hidden from all visibility by the
non-overridable declaration. In addition, a type extension is illegal if
somewhere within its immediate scope it has two visible components with the
same name. Similarly, the context_clause for a subunit is illegal if it
mentions (in a with_clause) some library unit, and there is a homograph of the
library unit that is visible at the place of the corresponding stub, and the
homograph and the mentioned library unit are both declared immediately within
the same declarative region. These rules also apply to dispatching operations
declared in the visible part of an instance of a generic unit. However, they
do not apply to other overloadable declarations in an instance; such
declarations may have type conformant profiles in the instance, so long as the
corresponding declarations in the generic were not type conformant.

      NOTES

27    5  Visibility for compilation units follows from the definition of the
      environment in 10.1.4, except that it is necessary to apply a
      with_clause to obtain visibility to a library_unit_declaration or
      library_unit_renaming_declaration.

28    6  In addition to the visibility rules given above, the meaning of the
      occurrence of a direct_name or selector_name at a given place in the
      text can depend on the overloading rules (see 8.6).

29    7  Not all contexts where an identifier, character_literal, or
      operator_symbol are allowed require visibility of a corresponding
      declaration. Contexts where visibility is not required are identified by
      using one of these three syntactic categories directly in a syntax rule,
      rather than using direct_name or selector_name.


8.4 Use Clauses


1     A use_package_clause achieves direct visibility of declarations that
appear in the visible part of a package; a use_type_clause achieves direct
visibility of the primitive operators of a type.


                                   Syntax

2     use_clause ::= use_package_clause | use_type_clause

3     use_package_clause ::= use package_name {, package_name};

4     use_type_clause ::= use type subtype_mark {, subtype_mark};


                               Legality Rules

5     A package_name of a use_package_clause shall denote a package.


                              Static Semantics

6     For each use_clause, there is a certain region of text called the scope
of the use_clause. For a use_clause within a context_clause of a
library_unit_declaration or library_unit_renaming_declaration, the scope is
the entire declarative region of the declaration. For a use_clause within a
context_clause of a body, the scope is the entire body and any subunits
(including multiply nested subunits). The scope does not include
context_clauses themselves.

7     For a use_clause immediately within a declarative region, the scope is
the portion of the declarative region starting just after the use_clause and
extending to the end of the declarative region. However, the scope of a
use_clause in the private part of a library unit does not include the visible
part of any public descendant of that library unit.

8     For each package denoted by a package_name of a use_package_clause whose
scope encloses a place, each declaration that occurs immediately within the
declarative region of the package is potentially use-visible at this place if
the declaration is visible at this place. For each type T or T'Class
determined by a subtype_mark of a use_type_clause whose scope encloses a
place, the declaration of each primitive operator of type T is potentially
use-visible at this place if its declaration is visible at this place.

9     A declaration is use-visible if it is potentially use-visible, except in
these naming-conflict cases:

10    A potentially use-visible declaration is not use-visible if the place
      considered is within the immediate scope of a homograph of the
      declaration.

11    Potentially use-visible declarations that have the same identifier are
      not use-visible unless each of them is an overloadable declaration.


                              Dynamic Semantics

12    The elaboration of a use_clause has no effect.


                                  Examples

13    Example of a use clause in a context clause:

14    with Ada.Calendar; use Ada;

15    Example of a use type clause:

16    use type Rational_Numbers.Rational; -- see 7.1
      Two_Thirds: Rational_Numbers.Rational := 2/3;


8.5 Renaming Declarations


1     A renaming_declaration declares another name for an entity, such as an
object, exception, package, subprogram, entry, or generic unit. Alternatively,
a subprogram_renaming_declaration can be the completion of a previous
subprogram_declaration.


                                   Syntax

2     renaming_declaration ::= 
            object_renaming_declaration
          | exception_renaming_declaration
          | package_renaming_declaration
          | subprogram_renaming_declaration
          | generic_renaming_declaration


                              Dynamic Semantics

3     The elaboration of a renaming_declaration evaluates the name that
follows the reserved word renames and thereby determines the view and entity
denoted by this name (the renamed view and renamed entity). A name that
denotes the renaming_declaration denotes (a new view of) the renamed entity.

      NOTES

4     8  Renaming may be used to resolve name conflicts and to act as a
      shorthand. Renaming with a different identifier or operator_symbol does
      not hide the old name; the new name and the old name need not be visible
      at the same places.

5     9  A task or protected object that is declared by an explicit
      object_declaration can be renamed as an object. However, a single task
      or protected object cannot be renamed since the corresponding type is
      anonymous (meaning it has no nameable subtypes). For similar reasons, an
      object of an anonymous array or access type cannot be renamed.

6     10  A subtype defined without any additional constraint can be used to
      achieve the effect of renaming another subtype (including a task or
      protected subtype) as in

7        subtype Mode is Ada.Text_IO.File_Mode;


8.5.1 Object Renaming Declarations


1     An object_renaming_declaration is used to rename an object.


                                   Syntax

2     object_renaming_declaration ::= defining_identifier : subtype_mark
       renames object_name;


                            Name Resolution Rules

3     The type of the object_name shall resolve to the type determined by the
subtype_mark.


                               Legality Rules

4     The renamed entity shall be an object.

5/1   The renamed entity shall not be a subcomponent that depends on
discriminants of a variable whose nominal subtype is unconstrained, unless
this subtype is indefinite, or the variable is aliased. A slice of an array
shall not be renamed if this restriction disallows renaming of the array. In
addition to the places where Legality Rules normally apply, these rules apply
also in the private part of an instance of a generic unit. These rules also
apply for a renaming that appears in the body of a generic unit, with the
additional requirement that even if the nominal subtype of the variable is
indefinite, its type shall not be a descendant of an untagged generic formal
derived type.


                              Static Semantics

6     An object_renaming_declaration declares a new view of the renamed object
whose properties are identical to those of the renamed view. Thus, the
properties of the renamed object are not affected by the renaming_declaration.
In particular, its value and whether or not it is a constant are unaffected;
similarly, the constraints that apply to an object are not affected by
renaming (any constraint implied by the subtype_mark of the
object_renaming_declaration is ignored).


                                  Examples

7     Example of renaming an object:

8     declare
         L : Person renames Leftmost_Person; -- see 3.10.1
      begin
         L.Age := L.Age + 1;
      end;


8.5.2 Exception Renaming Declarations


1     An exception_renaming_declaration is used to rename an exception.


                                   Syntax

2     exception_renaming_declaration ::= defining_identifier
       : exception renames exception_name;


                               Legality Rules

3     The renamed entity shall be an exception.


                              Static Semantics

4     An exception_renaming_declaration declares a new view of the renamed
exception.


                                  Examples

5     Example of renaming an exception:

6     EOF : exception renames Ada.IO_Exceptions.End_Error; -- see A.13


8.5.3 Package Renaming Declarations


1     A package_renaming_declaration is used to rename a package.


                                   Syntax

2     package_renaming_declaration ::= package defining_program_unit_name
       renames package_name;


                               Legality Rules

3     The renamed entity shall be a package.


                              Static Semantics

4     A package_renaming_declaration declares a new view of the renamed
package.


                                  Examples

5     Example of renaming a package:

6     package TM renames Table_Manager;


8.5.4 Subprogram Renaming Declarations


1     A subprogram_renaming_declaration can serve as the completion of a
subprogram_declaration; such a renaming_declaration is called a
renaming-as-body. A subprogram_renaming_declaration that is not a completion
is called a renaming-as-declaration, and is used to rename a subprogram
(possibly an enumeration literal) or an entry.


                                   Syntax

2     subprogram_renaming_declaration ::= subprogram_specification
       renames callable_entity_name;


                            Name Resolution Rules

3     The expected profile for the callable_entity_name is the profile given
in the subprogram_specification.


                               Legality Rules

4     The profile of a renaming-as-declaration shall be mode-conformant with
that of the renamed callable entity.

5/1   The profile of a renaming-as-body shall conform fully to that of the
declaration it completes. If the renaming-as-body completes that declaration
before the subprogram it declares is frozen, the profile shall be
mode-conformant with that of the renamed callable entity and the subprogram it
declares takes its convention from the renamed subprogram; otherwise, the
profile shall be subtype-conformant with that of the renamed callable entity
and the convention of the renamed subprogram shall not be Intrinsic. A
renaming-as-body is illegal if the declaration occurs before the subprogram
whose declaration it completes is frozen, and the renaming renames the
subprogram itself, through one or more subprogram renaming declarations, none
of whose subprograms has been frozen.

6     A name that denotes a formal parameter of the subprogram_specification
is not allowed within the callable_entity_name.


                              Static Semantics

7     A renaming-as-declaration declares a new view of the renamed entity. The
profile of this new view takes its subtypes, parameter modes, and calling
convention from the original profile of the callable entity, while taking the
formal parameter names and default_expressions from the profile given in the
subprogram_renaming_declaration. The new view is a function or procedure,
never an entry.


                              Dynamic Semantics

7.1/1 For a call to a subprogram whose body is given as a renaming-as-body,
the execution of the renaming-as-body is equivalent to the execution of a
subprogram_body that simply calls the renamed subprogram with its formal
parameters as the actual parameters and, if it is a function, returns the
value of the call.

8     For a call on a renaming of a dispatching subprogram that is overridden,
if the overriding occurred before the renaming, then the body executed is that
of the overriding declaration, even if the overriding declaration is not
visible at the place of the renaming; otherwise, the inherited or predefined
subprogram is called.


                          Bounded (Run-Time) Errors

8.1/1 If a subprogram directly or indirectly renames itself, then it is a
bounded error to call that subprogram. Possible consequences are that
Program_Error or Storage_Error is raised, or that the call results in infinite
recursion.

      NOTES

9     11  A procedure can only be renamed as a procedure. A function whose
      defining_designator is either an identifier or an operator_symbol can be
      renamed with either an identifier or an operator_symbol; for renaming as
      an operator, the subprogram specification given in the
      renaming_declaration is subject to the rules given in 6.6 for operator
      declarations. Enumeration literals can be renamed as functions;
      similarly, attribute_references that denote functions (such as
      references to Succ and Pred) can be renamed as functions. An entry can
      only be renamed as a procedure; the new name is only allowed to appear
      in contexts that allow a procedure name. An entry of a family can be
      renamed, but an entry family cannot be renamed as a whole.

10    12  The operators of the root numeric types cannot be renamed because
      the types in the profile are anonymous, so the corresponding
      specifications cannot be written; the same holds for certain attributes,
      such as Pos.

11    13  Calls with the new name of a renamed entry are
      procedure_call_statements and are not allowed at places where the syntax
      requires an entry_call_statement in conditional_ and timed_entry_calls,
      nor in an asynchronous_select; similarly, the Count attribute is not
      available for the new name.

12    14  The primitiveness of a renaming-as-declaration is determined by its
      profile, and by where it occurs, as for any declaration of (a view of) a
      subprogram; primitiveness is not determined by the renamed view. In
      order to perform a dispatching call, the subprogram name has to denote a
      primitive subprogram, not a non-primitive renaming of a primitive
      subprogram.


                                  Examples

13    Examples of subprogram renaming declarations:

14    procedure My_Write(C : in Character) renames Pool(K).Write; --  see 4.1.3

15    function Real_Plus(Left, Right : Real   ) return Real    renames "+";
      function Int_Plus (Left, Right : Integer) return Integer renames "+";

16    function Rouge return Color renames Red;  --  see 3.5.1
      function Rot   return Color renames Red;
      function Rosso return Color renames Rouge;

17    function Next(X : Color) return Color renames Color'Succ; -- see 3.5.1

18    Example of a subprogram renaming declaration with new parameter names:

19    function "*" (X,Y : Vector) return Real renames Dot_Product; -- see 6.1

20    Example of a subprogram renaming declaration with a new default
expression:

21    function Minimum(L : Link := Head) return Cell renames Min_Cell; -- see 6.1


8.5.5 Generic Renaming Declarations


1     A generic_renaming_declaration is used to rename a generic unit.


                                   Syntax

2     generic_renaming_declaration ::= 
          generic package       defining_program_unit_name
       renames generic_package_name;
        | generic procedure     defining_program_unit_name
       renames generic_procedure_name;
        | generic function      defining_program_unit_name
       renames generic_function_name;


                               Legality Rules

3     The renamed entity shall be a generic unit of the corresponding kind.


                              Static Semantics

4     A generic_renaming_declaration declares a new view of the renamed
generic unit.

      NOTES

5     15  Although the properties of the new view are the same as those of the
      renamed view, the place where the generic_renaming_declaration occurs
      may affect the legality of subsequent renamings and instantiations that
      denote the generic_renaming_declaration, in particular if the renamed
      generic unit is a library unit (see 10.1.1).


                                  Examples

6     Example of renaming a generic unit:

7     generic package Enum_IO renames Ada.Text_IO.Enumeration_IO;  -- see A.10.10


8.6 The Context of Overload Resolution


1     Because declarations can be overloaded, it is possible for an occurrence
of a usage name to have more than one possible interpretation; in most cases,
ambiguity is disallowed. This clause describes how the possible
interpretations resolve to the actual interpretation.

2     Certain rules of the language (the Name Resolution Rules) are considered
``overloading rules''. If a possible interpretation violates an overloading
rule, it is assumed not to be the intended interpretation; some other possible
interpretation is assumed to be the actual interpretation. On the other hand,
violations of non-overloading rules do not affect which interpretation is
chosen; instead, they cause the construct to be illegal. To be legal, there
usually has to be exactly one acceptable interpretation of a construct that is
a ``complete context'', not counting any nested complete contexts.

3     The syntax rules of the language and the visibility rules given in 8.3
determine the possible interpretations. Most type checking rules (rules that
require a particular type, or a particular class of types, for example) are
overloading rules. Various rules for the matching of formal and actual
parameters are overloading rules.


                            Name Resolution Rules

4     Overload resolution is applied separately to each complete context, not
counting inner complete contexts. Each of the following constructs is a
complete context:

5     A context_item.

6     A declarative_item or declaration.

7     A statement.

8     A pragma_argument_association.

9     The expression of a case_statement.

10    An (overall) interpretation of a complete context embodies its meaning,
and includes the following information about the constituents of the complete
context, not including constituents of inner complete contexts:

11    for each constituent of the complete context, to which syntactic
      categories it belongs, and by which syntax rules; and

12    for each usage name, which declaration it denotes (and, therefore, which
      view and which entity it denotes); and

13    for a complete context that is a declarative_item, whether or not it is
      a completion of a declaration, and (if so) which declaration it
      completes.

14    A possible interpretation is one that obeys the syntax rules and the
visibility rules. An acceptable interpretation is a possible interpretation
that obeys the overloading rules, that is, those rules that specify an
expected type or expected profile, or specify how a construct shall resolve or
be interpreted.

15    The interpretation of a constituent of a complete context is determined
from the overall interpretation of the complete context as a whole. Thus, for
example, ``interpreted as a function_call,'' means that the construct's
interpretation says that it belongs to the syntactic category function_call.

16    Each occurrence of a usage name denotes the declaration determined by
its interpretation. It also denotes the view declared by its denoted
declaration, except in the following cases:

17    If a usage name appears within the declarative region of a
      type_declaration and denotes that same type_declaration, then it denotes
      the current instance of the type (rather than the type itself). The
      current instance of a type is the object or value of the type that is
      associated with the execution that evaluates the usage name.

18    If a usage name appears within the declarative region of a
      generic_declaration (but not within its generic_formal_part) and it
      denotes that same generic_declaration, then it denotes the current
      instance of the generic unit (rather than the generic unit itself). See
      also 12.3.

19    A usage name that denotes a view also denotes the entity of that view.

20    The expected type for a given expression, name, or other construct
determines, according to the type resolution rules given below, the types
considered for the construct during overload resolution. The type resolution
rules provide support for class-wide programming, universal numeric literals,
dispatching operations, and anonymous access types:

21    If a construct is expected to be of any type in a class of types, or of
      the universal or class-wide type for a class, then the type of the
      construct shall resolve to a type in that class or to a universal type
      that covers the class.

22    If the expected type for a construct is a specific type T, then the type
      of the construct shall resolve either to T, or:

        23    to T'Class; or

        24    to a universal type that covers T; or

        25    when T is an anonymous access type (see 3.10) with designated
              type D, to an access-to-variable type whose designated type is
              D'Class or is covered by D.

26    In certain contexts, such as in a subprogram_renaming_declaration, the
Name Resolution Rules define an expected profile for a given name; in such
cases, the name shall resolve to the name of a callable entity whose profile
is type conformant with the expected profile.


                               Legality Rules

27    When the expected type for a construct is required to be a single type
in a given class, the type expected for the construct shall be determinable
solely from the context in which the construct appears, excluding the
construct itself, but using the requirement that it be in the given class; the
type of the construct is then this single expected type. Furthermore, the
context shall not be one that expects any type in some class that contains
types of the given class; in particular, the construct shall not be the
operand of a type_conversion.

28    A complete context shall have at least one acceptable interpretation; if
there is exactly one, then that one is chosen.

29    There is a preference for the primitive operators (and ranges) of the
root numeric types root_integer and root_real. In particular, if two
acceptable interpretations of a constituent of a complete context differ only
in that one is for a primitive operator (or range) of the type root_integer or
root_real, and the other is not, the interpretation using the primitive
operator (or range) of the root numeric type is preferred.

30    For a complete context, if there is exactly one overall acceptable
interpretation where each constituent's interpretation is the same as or
preferred (in the above sense) over those in all other overall acceptable
interpretations, then that one overall acceptable interpretation is chosen.
Otherwise, the complete context is ambiguous.

31    A complete context other than a pragma_argument_association shall not be
ambiguous.

32    A complete context that is a pragma_argument_association is allowed to
be ambiguous (unless otherwise specified for the particular pragma), but only
if every acceptable interpretation of the pragma argument is as a name that
statically denotes a callable entity. Such a name denotes all of the
declarations determined by its interpretations, and all of the views declared
by these declarations.

      NOTES

33    16  If a usage name has only one acceptable interpretation, then it
      denotes the corresponding entity. However, this does not mean that the
      usage name is necessarily legal since other requirements exist which are
      not considered for overload resolution; for example, the fact that an
      expression is static, whether an object is constant, mode and subtype
      conformance rules, freezing rules, order of elaboration, and so on.

34    Similarly, subtypes are not considered for overload resolution (the
      violation of a constraint does not make a program illegal but raises an
      exception during program execution).

