When is a rename not a rename?

When is a rename not a rename?

[Adam Beneschan]

I've always assumed that if you declare a name to be a rename of some other entity (*), there wouldn't be any impact on the program, other than that you can use the new name to mean the same thing as the thing that it renames.

In particular, for library unit packages, if P2 is a library unit package that renames P1, then a unit that says "with P2;" should work the same as one that says "with P1;" after you've done whatever is necessary to make sure all names in the unit refer to the same entities.  Right?

I've just discovered that this isn't the case...

with P1;
with P3;
package P2 renames P1;

Now, a program that says "with P2;" may operate differently from one that with's P1--because saying "with P2" will cause P3's elaboration code to be executed at the beginning of the program, while saying "with P1" will not [unless P3 is included in the program via some other path].

I wonder if this was the intent, or if it's a "bug" in the language definition?

                           -- Adam


(*) Not counting a renaming-as-body, which is different because the first declaration of the name is *not* a renaming declaration.

Re: When is a rename not a rename?

[Randy Brukardt]

What else could it mean? We don't want to be ignoring "with" clauses in one 
rarely used case, so it has to cause a semantic dependence here.

And this doesn't have anything to do with the rename per-se; this is a 
compilation unit like any other (that happens to be a rename), and it is the 
compilation unit that has this effect, not the rename. I always think of all 
compilation units as packages (imagining an invisible package wrapping 
anything that isn't a normal package), and when you do that, this makes 
plenty of sense.

                               Randy.

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:6d66d1c4-ed22-446b-a9d7-dc806ae1ef8f@googlegroups.com...
I've always assumed that if you declare a name to be a rename of some other 
entity (*), there wouldn't be any impact on the program, other than that you 
can use the new name to mean the same thing as the thing that it renames.

In particular, for library unit packages, if P2 is a library unit package 
that renames P1, then a unit that says "with P2;" should work the same as 
one that says "with P1;" after you've done whatever is necessary to make 
sure all names in the unit refer to the same entities.  Right?

I've just discovered that this isn't the case...

with P1;
with P3;
package P2 renames P1;

Now, a program that says "with P2;" may operate differently from one that 
with's P1--because saying "with P2" will cause P3's elaboration code to be 
executed at the beginning of the program, while saying "with P1" will not 
[unless P3 is included in the program via some other path].

I wonder if this was the intent, or if it's a "bug" in the language 
definition?

                           -- Adam


(*) Not counting a renaming-as-body, which is different because the first 
declaration of the name is *not* a renaming declaration. 

Re: When is a rename not a rename?

[Adam Beneschan]

On Tuesday, January 29, 2013 4:28:29 PM UTC-8, Randy Brukardt wrote:
> What else could it mean? We don't want to be ignoring "with" clauses in one 
> rarely used case, so it has to cause a semantic dependence here.
> 
> And this doesn't have anything to do with the rename per-se; this is a 
> compilation unit like any other (that happens to be a rename), and it is the 
> compilation unit that has this effect, not the rename. I always think of all 
> compilation units as packages (imagining an invisible package wrapping 
> anything that isn't a normal package), and when you do that, this makes 
> plenty of sense.

Yes... it just requires me to change my thinking a little bit about what a "rename" means.  I thought it set up a synonym, but in the case of a library-level rename it isn't quite true; thinking about it as a wrapper makes more sense.  It's just a bit surprising, and I was curious whether this was something that was considered when the semantics were defined in Ada 95.  

And no, I wouldn't have wanted "with" clauses to be ignored, but the language could have made "with" clauses on library-level renames illegal except for "with" clauses that denoted the renamed unit or an ancestor or a unit on which the renamed unit's specification depends semantically, or something along those lines.  Not that I'm proposing any such change now.

                              -- Adam

Re: When is a rename not a rename?

[Dmitry A. Kazakov]

On Tue, 29 Jan 2013 16:52:03 -0800 (PST), Adam Beneschan wrote:

> Yes... it just requires me to change my thinking a little bit about what a
> "rename" means.

I wished the rule that a renaming shall never conflict with the thing is
renames [and never creates logically new objects].

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: When is a rename not a rename?

[ytomino]

2013年1月30日水曜日 18時31分21秒 UTC+9 Dmitry A. Kazakov:
> I wished the rule that a renaming shall never conflict with the thing is
> renames [and never creates logically new objects].

with XXX;
package YYY is
   subype T is XXX.T;
   function "=" (Left, Right : T) return Boolean renames XXX."=";
end YYY;

...
declare
   use YYY; -- introduce YYY."="
   use type YYY.T; -- introduce XXX."="
   A, B : T;
begin
   if A = B then -- error because two "=" are conflicted!
...

I wish this case may be not conflicted.
There is probably no way to create a package having any entities perfectly rename something in another package.

Re: When is a rename not a rename?

[Ada novice]

On Tuesday, January 29, 2013 2:24:55 AM UTC+1, Adam Beneschan wrote:
> I've always assumed that if you declare a name to be a rename of some other entity (*), there wouldn't be any impact on the program, other than that you can use the new name to mean the same thing as the thing that it renames.

Very interesting discussion and I am "perplexed" if what you say is not true. If you have a minimal example that is proving the contrary, please post it here.

Thanks.
YC

Re: When is a rename not a rename?

[Dmitry A. Kazakov]

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:

with Ada.IO_Exceptions;
procedure Test is
   package P is
      End_Error : exception renames Ada.IO_Exceptions.End_Error;
   end P;
   use P, Ada.IO_Exceptions;
begin
   null;
exception
   when End_Error => -- Compile error, should be none
      null;
end Test;

This is "diamond diagram" constructed using renaming:

procedure Test is
   package P is
      I : Integer;
   end P;
   package Q is
      J : Integer renames P.I;
   end Q;
   package R is
      J : Integer renames P.I;
   end R;
   use Q, R;
   X : Integer := J; -- Compile error, should be none
begin
   null;
end Test;

[Diamond diagram is common-place bogus argument against MI]

Yet another example when rename is something totally broken:

with Ada.Text_IO; use Ada.Text_IO;
procedure Test is
   X : Integer;
   Y : Positive renames X;
begin
   Y := -1;
   Put_Line ("And today positive number is " & Integer'Image (Y));
end Test;

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: When is a rename not a rename?

[Adam Beneschan]

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

Re: When is a rename not a rename?

[ytomino]

How is my previous post?

First,

package XXX is
   type T is private;
   function "=" (Left, Right : T) return Boolean;
end XXX;

declare
   use XXX;
   use type T;
   A, B : T;
begin
   if A = B then -- legal

Then, ready new package YYY renaming XXX.

with XXX;
package YYY is
   subtype T is XXX.T;
   function "=" (Left, Right : T) return Boolean renames XXX."=";
end YYY;

And, replace.

declare
   use YYY; -- change here
   use type T;
   A, B : T;
begin
   if A = B then -- error !!

I want to split an existing package into some implementation files and one interface file that renames all declarations in each implementation file.

For example, from

package Large is
   type T1 is private;
   procedure Proc1 (Obj : T1);
   type T1_Supplement is private;
   procedure Proc2 (Obj : T1; Arg : T1_Supplement);
   ...

   type T2;
   ...
end Large;

to

with Small1, Small2;
package Large is
   subtype T1 is Small1.T1;
   procedure Proc1 (Obj : T1) renames Small1.Proc1;
   subtype T1_Supplement is Small1.T1_Supplement;
   procedure Primitive (Obj : T1; Arg : T1_Supplement) renamens Small1.Proc2;
   ... renames all entities from Small1 ...

   subtype T2 is Small2.T2;
   ... renames all entities from Small2 ...
end Large;

But, "use type" causes above confliction.
("type T1 is new Small1.T1;" resolves for only T1, but T1_Supplement should be renamed still.)

Re: When is a rename not a rename?

[Adam Beneschan]

On Friday, February 1, 2013 10:31:06 AM UTC-8, ytomino wrote:
> How is my previous post?
> 
> First,
> 
> package XXX is
>    type T is private;
>    function "=" (Left, Right : T) return Boolean;
> end XXX;
> 
> declare
>    use XXX;
>    use type T;
>    A, B : T;
> begin
>    if A = B then -- legal
> 
> Then, ready new package YYY renaming XXX.
> 
> with XXX;
> package YYY is
>    subtype T is XXX.T;
>    function "=" (Left, Right : T) return Boolean renames XXX."=";
> end YYY;
> 
> And, replace.
> 
> declare
>    use YYY; -- change here
>    use type T;
>    A, B : T;
> begin
>    if A = B then -- error !!

I can understand why this would be annoying.  It seems like a problem.  I don't know if it's enough of a problem to consider fixing the language.  It wouldn't be trivial.  Perhaps 8.6(30) could be modified to add some concept of two acceptable interpretations that are essentially the same because the usage names end up denoting the same entity via renaming.  It seems hard to get the wording right.  Plus you have to deal with things like this:

package XXX is
   type T is private;
   procedure Operation (Obj : in out T; Offset : Integer := 0);
end XXX;

package YYY is
   subtype T renames XXX.T;
   procedure Operation (Obj : in out T; Offset : Integer := -1) 
       renames XXX.Operation;
end YYY;

...
use YYY;
use type T;
Z : T;

Operation(Z);

Although the two Operation's that could be denoted by this actually refer to the same declaration after renaming is considered, it's still ambiguous since we don't know what should be passed for Offset.  Parameter names can also be different in a subprogram rename, which can pose another problem.  The language rules would have to be written to allow the case you're interested in but disallow examples like mine.  Not easy.

                            -- Adam

Re: When is a rename not a rename?

[ytomino]

On Saturday, February 2, 2013 10:40:40 AM UTC+9, Adam Beneschan wrote:
> Although the two Operation's that could be denoted by this actually refer to the same declaration after renaming is considered, it's still ambiguous since we don't know what should be passed for Offset.  Parameter names can also be different in a subprogram rename, which can pose another problem.  The language rules would have to be written to allow the case you're interested in but disallow examples like mine.  Not easy.

Right you are. I'm afraid for/have to be careful not to make typo in renaming.

I think... in the case, human have not to write "renames" by hand. Actually, There are some typo in examples (including mine...orz) presented in this thread. :-)

"Integrated" nested packages proposed in AI05-0135 seems easy and good to me.

with XXX;
package YYY is 
   use package <Included_XXX> renames XXX;
end YYY;

with Small1, Small2;
package Large is
   use package <Included_Small_1> renames Small1;
   use package <Included_Small_2> renames Small2;
end Large;

Perhaps, it too makes large headers like Win32Ada more simpler.

As another solution, I have to remove "use type" from client code because "use" implies "use type". But I have to remove "use type" from other person's code...

Re: When is a rename not a rename?

[Robert A Duff]

Adam Beneschan <adam@irvine.com> writes:

> I can understand why this would be annoying.  It seems like a problem.
> I don't know if it's enough of a problem to consider fixing the
> language.  It wouldn't be trivial.

Nothing related to visibility is trivial, but I think it could be
done, and would be an improvement to the language.  See 8.3(12.3),
where something similar is going on.

On the other hand, compiler writers aren't going to want to mess around
with this part of their compiler.

A similar example:  Suppose we have:

    X : constant T := Some_Package.X;

And suppose both X's are potentially use-visible at some
place.  You might want to be able to refer to X.  (Currently,
the X's hide each other, and I doubt that's going to change.)

- Bob

Re: When is a rename not a rename?

[Shark8]

On Saturday, February 2, 2013 8:26:01 AM UTC-6, Robert A Duff wrote:
> 
> A similar example:  Suppose we have:
> 
>     X : constant T := Some_Package.X;
> 
> And suppose both X's are potentially use-visible at some
> place.  You might want to be able to refer to X.  (Currently,
> the X's hide each other, and I doubt that's going to change.)

Shouldn't the compiler complain of ambiguity and force a fully-qualified referral in that case? (Though you could 'promote' one's visibility to 'default' via renames in the current compilation-unit's context.)

Re: When is a rename not a rename?

[Brian Drummond]

On Fri, 01 Feb 2013 09:32:42 -0800, Adam Beneschan wrote:

> 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:
> 
> Another possible example is when a subprogram renames another one but
> changes a default parameter:

There was also a recent specimen where a rename made a procedure's 
parameter disappear!

The trick was something like renaming an object.method call to just 
renamed_method.

I forget the precise details but I recall it was legal; taking its access 
was not (though astonishingly, it worked in current Gnat revisions)

- Brian

Re: When is a rename not a rename?

[AdaMagica]

On Saturday, February 2, 2013 1:42:29 AM UTC+1, Brian Drummond wrote:
> On Fri, 01 Feb 2013 09:32:42 -0800, Adam Beneschan wrote:
> The trick was something like renaming an object.method call to just 
> renamed_method.
>
> I forget the precise details but I recall it was legal; taking its access 
> was not (though astonishingly, it worked in current Gnat revisions)

See
http://en.wikibooks.org/wiki/Ada_Programming/Subprograms#Renaming

package Some_Package is
  type Message_Type is tagged null record;
  procedure Print (Message: in Message_Type);
end Some_Package; 

with Some_Package;
procedure Main is
  Message: Some_Package.Message_Type;
  procedure Print renames Message.Print;  -- this has convention intrinsic, see RM 6.3.1(10.1/2)
  Method_Ref: access procedure := Print'Access;  -- thus taking 'Access should be illegal; GNAT GPL 2012 allows this
begin  -- All these calls are equivalent:
  Some_Package.Print (Message);  -- traditional call without use clause
  Message.Print;                 -- Ada 2005 method.object call - note: no use clause necessary
  Print;                         -- Message.Print is a parameterless procedure and can be renamed as such
  Method_Ref.all;                -- GNAT GPL 2012 allows illegal call via an access to the renamed procedure Print
                                 -- This has been corrected in the current version (as of Nov 22, 2012)
end Main;

Re: When is a rename not a rename?

[Brian Drummond]

On Sat, 02 Feb 2013 03:43:33 -0800, AdaMagica wrote:

> On Saturday, February 2, 2013 1:42:29 AM UTC+1, Brian Drummond wrote:
>> On Fri, 01 Feb 2013 09:32:42 -0800, Adam Beneschan wrote:
>> The trick was something like renaming an object.method call to just
>> renamed_method.

> See http://en.wikibooks.org/wiki/Ada_Programming/Subprograms#Renaming

Good to know where to find it again! And I didn't know Gnat GPL had 
closed the loophole.

This is one case where the Wikibook is better than dead tree references, 
I will bear that in mind in future.

- Brian

Re: When is a rename not a rename?

[AdaMagica]

On Sunday, February 3, 2013 12:50:38 PM UTC+1, Brian Drummond wrote:
> > See http://en.wikibooks.org/wiki/Ada_Programming/Subprograms#Renaming
> Good to know where to find it again! And I didn't know Gnat GPL had 
> closed the loophole.

I reported it to AdaCore, and it's been corrected in the supported version.
So I hope it wasn't to late and the correction will also be in GNAT GPL 2013 when it finally comes out.

> This is one case where the Wikibook is better than dead tree references,
> I will bear that in mind in future.
>
> - Brian

Re: When is a rename not a rename?

[Ada novice]

On Friday, February 1, 2013 6:32:42 PM UTC+1, Adam Beneschan wrote:

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


Thanks for these two very good examples. I shall be careful with renames from now on.

Thanks
YC

Re: When is a rename not a rename?

[Ada novice]

Thanks for the negative "today's positive number" example :).

I see that your examples may be looking at renaming the types of variables except in the 1st example.

If I use rename in a program, it is because I can have a general method of doing something plus some specific cases that require some changes in the general method. So I have e.g.

The file General_Method.ads as

With Specific_Case_A;
Package General_Method renames Specific_Case_A;
--With Specific_Case_B;
--Package General_Method renames Specific_Case_B;

Now I am thinking what I am really doing in my example: should it be package X renames Y or package Y renames X...whatever


YC