Re: When is a rename not a rename?

[Adam Beneschan <adam@irvine.com>]

On Friday, February 1, 2013 3:27:02 AM UTC-8, Dmitry A. Kazakov wrote:
> On Fri, 1 Feb 2013 02:44:21 -0800 (PST), Ada novice wrote:
> 
> > If you have a minimal example that is proving the contrary, please post it here.
> 
> Here is how renaming is not renaming:

These examples aren't close to what I was getting at.  I was trying to talk about cases where Y renames X; but if you replace X in your program with Y, and both programs are legal, the program runs differently.  (Not counting cases where changing X to Y causes changes in the meanings of other identifiers later in the program because of the visibility rules.)

Your first two examples are cases where you can't use a rename because of the language rules, so these are definitely not the same thing.  In the first case, you just don't like how the scoping rules apply to exception handlers--it has nothing to do with renaming.  The second case is one that probably could be fixed by language rules, although I doubt it will happen.  It's mildly annoying that an ambiguous identifier error can be triggered by two identifiers with the same name that rename the same entity.  The third case is the opposite of what I'm talking about: if you replace X := -1 with Y := -1 the program has the exact same behavior.  It may be annoying that the rename allows you to put an additional constraint on the renaming variable and then ignores it.  I agree that it may have been a mistake to allow this.  But it's still not the same thing I was discussing.

Here's an example that may answer YC's question:

package Pack1 is
   pragma Elaborate_Body;
end Pack1;

with Ada.Text_IO;
package body Pack1 is
begin
   Text_IO.Put_Line ("Pack1 is elaborated");
end Pack1;

package Pack2 is
end Pack2;

with Pack1, Pack2;
package Pack3 renames Pack2;

with Pack2;  -- with Pack3;  <=== HERE
procedure Test is
begin
    null;
end Test;

If you run Test, nothing happens; but if you change the HERE line to "with Pack3;", then when you run Test, it outputs "Pack1 is elaborated", even though Pack3 renames Pack2.  That's what I was talking about.  Pack3 is not a strict "rename" in the sense that I understand the term (and apparently Randy likes to think of it as a wrapper of sorts rather than a strict rename).

Another possible example is when a subprogram renames another one but changes a default parameter:

    procedure P1 (N1 : Integer; N2 : Integer := 0) is ...

    procedure P2 (N1 : Integer; N2 : Integer := 1) renames P1;

    P1(5);
    P2(5);

Another case where P2 renames P1, but changing P1 to P2 has a different effect.  I think this capability was allowed deliberately, though, with the expectation that it might be useful.  Probably, if you do something like this, you should put comments on P2 to make it clear that this isn't a strict rename---and similarly on Pack3 in my earlier example.

                               -- Adam