Expanded names

[NCOHEN@IBM.COM ("Norman H. Cohen")]

Marc Graham presents a library package TESTNAMES with the following
body:

   package body testnames is

       outer_constant : constant := 3.14159;

       procedure testnames (outer_constant : integer) is
       begin
          ... testnames.outer_constant ...
       end testnames;
   end testnames;

He observes that the occurrence of "testnames.outer_constant" in the
procedure body refers to the formal parameter, not the named number, and
asks whether there is any way to denote the named number from within
the procedure body.  Since all library units are considered to be
declared directly within package STANDARD, the name
STANDARD.TESTNAMES.OUTER_CONSTANT will work.  (See the notes in RM
8.6(3) and 10.1(10).)

Marc also asserts that if the outer TESTNAMES were a procedure rather
than a package, the expanded name TESTNAMES.OUTER_CONTEXT would be
illegal within the inner TESTNAMES, citing RM 4.1.3(18):

   If the prefix is the name of a subprogram or accept statement and
   there is more than one visible enclosing subprogram or accept
   statement of this name, the expanded name is ambiguous, independently
   of the selector.

The key word here is VISIBLE.  Marc's original example works as it does
because the inner declaration of TESTNAMES hides the outer declaration
throughout the immediate scope of the inner declaration (see 8.3(15)).
(Marc declares the TESTNAMES procedure within the TESTNAMES package
declaration, not shown above, so the package name is hidden from there
through the rest of the package declaration, as well as throughout the
package body.)  In the case of subprograms and accept statements,
overloading rules allow both an inner and an outer declaration of the
same name to be visible--if the parameter and result type profiles are
different.  Thus a special rule is provided.  (The alternative would
have been to use the innermost enclosing unit, but then 4.1.3(f) could
not have been phrased in terms of visibility rules.  Simplicity of
presentation was apparently chosen over uniform semantics for naming
enclosing units in prefixes, but the issue only arises in pathological
programs anyway.)  Here is a (suitably pathological) illustration:

   procedure P (X: in Integer) is     --P#1

      procedure P (X: in Float) is    --P#2
         -- Both P#1 and P#2 visible here since profiles are different
         ... P.X ... -- Illegal by RM 4.1.3(18)
      end P;

      procedure P (X: in Integer) is  --P#3
         -- P#1 is hidden by P#3 here.
         ... P.X ... -- Legal, refers to formal parameter of P#3.
      end P;

   end P;

Finally, Marc asks about RM 4.1.3(19), which concerns a completely
different pathology:  If F is a parameterless function returning a
record value with component C, then within a unit named F, the name
F.C could be interpreted either as a call on the function followed by
selection of the record component (which 4.1.3(19) explicitly excludes)
or as the name of an entity C declared immediately within unit F.