"shadow" package hierarchy using renaming of child packages

"shadow" package hierarchy using renaming of child packages

[Oliver Kellogg]

Hi,

I was quite amazed to find that GNAT lets me rename a child package
of one hierarchy to a child package of a different hierarchy (i.e. having a different root.)

Does this work on other compilers too?

Thanks,

   Oliver


-- file: foo.ads (original root package)
package Foo is
   type T is new Integer;
end Foo;

-- file: foo-child.ads
package Foo.Child is
   function Create return T;
end Foo.Child;

-- file: foo-child.adb
package body Foo.Child is
   function Create return T is
   begin
      return 0;
   end Create;
end Foo.Child;

-- file: shadow.ads (a different root package)
with Foo;
package Shadow is
   subtype T is Foo.T;
   type Other_Stuff is range 999 .. 1000;
end Shadow;

-- file: shadow-child.ads
with Foo.Child;
package Shadow.Child renames Foo.Child;

-- file: test_shadow.adb
with Shadow.Child;
procedure Test_Shadow is
   I : Shadow.T := Shadow.Child.Create;
begin
   null;
end Test_Shadow;

Re: "shadow" package hierarchy using renaming of child packages

[AdaMagica]

So was I. But you cannot use a renaming as a parent of a further package. So there is no real way to mix two package trees.

package Shadow.Child.Grandchild is ...
1:1  parent unit cannot be a renaming

That's at least what GNAT GPL 2013 says. I didn't check what the RM says.

Re: "shadow" package hierarchy using renaming of child packages

[Shark8]

On Sunday, June 30, 2013 2:43:59 PM UTC-6, AdaMagica wrote:
> So was I. But you cannot use a renaming as a parent of a further package. So there is no real way to mix two package trees.
> 
> 
> package Shadow.Child.Grandchild is ...
> 1:1  parent unit cannot be a renaming
> 
> That's at least what GNAT GPL 2013 says. I didn't check what the RM says.

Is there an ARM section for that? I can't seem to find it if there is, and it seems rather an arbitrary limitation, so I'd like to see it.

Re: "shadow" package hierarchy using renaming of child packages

[J-P. Rosen]

Le 01/07/2013 03:34, Shark8 a écrit :
> On Sunday, June 30, 2013 2:43:59 PM UTC-6, AdaMagica wrote:
>> So was I. But you cannot use a renaming as a parent of a further
>> package. So there is no real way to mix two package trees.
>> 
>> 
>> package Shadow.Child.Grandchild is ... 1:1  parent unit cannot be a
>> renaming
>> 
>> That's at least what GNAT GPL 2013 says. I didn't check what the RM
>> says.
> 
> Is there an ARM section for that? I can't seem to find it if there
> is, and it seems rather an arbitrary limitation, so I'd like to see
> it.
> 
10.1.1(13): The parent unit of a library_item shall be a library package
or generic library package

... and not a library_package_renaming_declaration

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: "shadow" package hierarchy using renaming of child packages

[AdaMagica]

And if you think about it, a child package is not very different from a nested package, and these have been around since Ada 83 (or even 80?).

Re: "shadow" package hierarchy using renaming of child packages

[Oliver Kellogg]

On Sunday, June 30, 2013 10:43:59 PM UTC+2, AdaMagica wrote:
>
> So was I. But you cannot use a renaming as a parent of a further package.
> So there is no real way to mix two package trees.

Understood. Still, even just one level of child packages would seem interesting. For this to work, IMHO there must be some notion of "structural equivalence" of the shadow root with respect to the original root. In the example, apparently the declaration "subtype T is Foo.T;" in the Shadow package spec creates the structural equivalence.

Meanwhile, I've been able to successfully build the example using an old Apex-3.2.0b.

I'm still not sure of chapter and verse in the RM that defines this.

-- Oliver

Re: "shadow" package hierarchy using renaming of child packages

[AdaMagica]

On Monday, July 1, 2013 10:29:25 AM UTC+2, Oliver Kellogg wrote:

> Understood. Still, even just one level of child packages would seem interesting. For this to work, IMHO there must be some notion of "structural equivalence" of the shadow root with respect to the original root. In the example, apparently the declaration "subtype T is Foo.T;" in the Shadow package spec creates the structural equivalence.

No, it hasn't anything to do with structural equivalence. Just compare:

with P1;                          with P1;
package P2 is                     package P2.Ren renames P1;
  package Ren renames P1;
end P2;

Re: "shadow" package hierarchy using renaming of child packages

[Oliver Kellogg]

On Monday, July 1, 2013 11:37:23, UTC+2 AdaMagica wrote:
> 
> > [...] In the example, apparently the declaration "subtype T is Foo.T;" in the
> > Shadow package spec creates the structural equivalence.
> No, it hasn't anything to do with structural equivalence.
> Just compare:
> [...]

Yikes, you're right!

Looking from the user perspective:
Imagine Shadow to preexist, with much code written against its API.
Imagine that a new package Foo representing a light-weight subset of the Shadow API is added to the system at a later date. Now the interesting thing is that the existing applications do not need to be changed.
In shadow-test.adb,
   I : Shadow.T := Shadow.Child.Create;
the declaration of T in Shadow ensures that.

Thanks.

Re: "shadow" package hierarchy using renaming of child packages

[Adam Beneschan]

On Sunday, June 30, 2013 10:46:24 PM UTC-7, J-P. Rosen wrote:

> 10.1.1(13): The parent unit of a library_item shall be a library package
> or generic library package
> 
> ... and not a library_package_renaming_declaration

Also, 10.1.1(15) is more explicit, I think: "A parent_unit_name (which can be used within a defining_program_unit_name of a library_item and in the separate clause of a subunit), and each of its prefixes, shall not denote a renaming_declaration."  The name following the word "package" is a defining_program_unit_name, therefore any ancestor unit name that's part of the defining_program_unit_name can't be a renaming unit.

I don't think it's an arbitrary restriction, either.  Child units are able to directly access names defined in their ancestor units.  If we were able to write

   package A.B.C renames X.Y.Z;
  
   package A.B.C.D is ...

A.B.C.D would have direct visibility to names declared in its ancestors--but what are its ancestors?  A and A.B, or X and X.Y?  Keep in mind that the ancestor A.B.C is a rename of X.Y.Z and the specification of X.Y.Z will be able to directly refer to names in X and X.Y.  I think that allowing A.B.C.D here would lead to a big semantic mess.

                             -- Adam