[Repost with proper title]

I pretty much follow the rational requiring children of generics that are
meant to be used by users of a generic also be generic. But what about
the case that the child is only introduced for "separation of concerns"
and "information hiding" in the body of a generic package: Why can't
_private_ children of a generic _always_ for use only in the implementation of the parent unit be allowed? That seems to me to be only a little more flexible version of the allowed arrangement where the desired
functionality is expressed in a body-local package that has _its_ implementation as separate stub.

So, I mean I have a situation where I like to be able to do the following
but can't.

generic
....
package Generic_Package is
procedure Parent_Procedure;
....
end;
private
package Generi
_Package.Child is
procedure GPC_Procedure;
....
end;

package body Generic_Package is
....
procedure Parent_Procedure is separate;
....
end;
with Generic_Package.C
hild;
separate (Generic_Package)
procedure Parent_Procedure is
begin
....
Generic_Package.Child.GPC_Procedure;
....
end;

Children of generic packages are also generic.

generic
package P is
end P;

generic
package P.C is
end P.C;

private generic
package P.R is
end P.R;

Problem with private children is that they are not there for the client. Thus they can only be instantiated within another package:

package body P.C is
package Inst is new P.R;
end P.C;

On Monday, April 26, 2021 at 12:41:47 PM UTC-4, AdaMagica wrote:
> Children of generic packages are also generic.

I do understand that that is the current stipulation. My question is rational
for including the private children. It seems that a child arrangement such as
I presented (non-generic but _private_) would not have caused any problems
and might have been allowable. So, why not?

Vincent Marciante schrieb am Montag, 26. April 2021 um 18:53:09 UTC+2:
> On Monday, April 26, 2021 at 12:41:47 PM UTC-4, AdaMagica wrote:
> > Children of generic packages are also generic.
> I do understand that that is the current stipulation. My question is rational
> for including the private children. It seems that a child arrangement such as
> I presented (non-generic but _private_) would not have caused any problems
> and might have been allowable. So, why not?

Generic packages are not packages. So a child of a generic package cannot be a package. This is the logic.
I do not know what rules would have to be defined for making this allowed.

On Monday, April 26, 2021 at 1:16:26 PM UTC-4, AdaMagica wrote:
> Vincent Marciante schrieb am Montag, 26. April 2021 um 18:53:09 UTC+2:
> > On Monday, April 26, 2021 at 12:41:47 PM UTC-4, AdaMagica wrote:
> > > Children of generic packages are also generic.
> > I do understand that that is the current stipulation. My question is rational
> > for including the private children. It seems that a child arrangement such as
> > I presented (non-generic but _private_) would not have caused any problems
> > and might have been allowable. So, why not?
> Generic packages are not packages. So a child of a generic package cannot be a package. This is the logic.
> I do not know what rules would have to be defined for making this allowed.

Considering private children of generic to be "per instance" would allow the body of
a generic to be less cluttered - not having to textually contain the spec of the child
and would allow more flexible/restrictable visibility: any (separate) unit that needs
to see the private child unit (and only those units) could then "with" the unit.

Currently, one would have to make the private child unit generic and then instantiate
it in the body of the parent at a place were all subunits that require its use can see it,
however, that might cause either (1) a less-than-preferable ordering of units in the body
or (2) more-than desired visibility of the unit.

Because the above can be done and ends up being very similar to the/my desired
arrangement (with the added costs described previously) why not arrange to allow
private non-generic children of a generic?

Vincent Marciante schrieb am Mittwoch, 28. April 2021 um 14:09:23 UTC+2:
> Currently, one would have to make the private child unit generic and then instantiate
> it in the body of the parent at a place were all subunits that require its use can see it,

The body of the parent is invisible to all children. It's the other way round: The body of the parent can with child units.
You have to instantiate a private child unit in the private part of the parent's spec to make it visible to all other children
(this is a simplified description of the facts).

Randy can perhaps say more about your ideas. Post this question to Ada Comment.

Vincent Marciante schrieb am Montag, 26. April 2021 um 17:43:36 UTC+2:
> Why can't
> _private_ children of a generic _always_ for use only in the implementation of the parent unit be allowed?

The reason is quite simple. If the generic parent is instantiated more than once, a nongeneric child (private or public) would be used by all of them. This does not make sense.

On Thursday, April 29, 2021 at 4:57:21 AM UTC-4, AdaMagica wrote:
> Vincent Marciante schrieb am Montag, 26. April 2021 um 17:43:36 UTC+2:
> > Why can't
> > _private_ children of a generic _always_ for use only in the implementation of the parent unit be allowed?
> The reason is quite simple. If the generic parent is instantiated more than once, a nongeneric child (private or public) would be used by all of them. This does not make sense.

I am asking about a _new_ rule that would make private non-generic child units of generics be like
ones declared in the body of a generic but with their body stubbed and presented in a separate
(_not_ being shared by instances - _not_ being usable/visible in the spec of the generic).

That would allow only the separate bodies of subprograms of the generic that need to use
the private (nongeneric) child of the generic to bring it into context by with'ng it. That would
allow easier restriction of visibility - better information hiding.

(My specific need is in trying to keep down code duplication in a few different implementations
of a generic package: separate body parts/files for each different implementation appear in different
subdirectories and the build system picks the correct ones depending on the variant being built.
Without what we are talking about, I think that I am going to have to declare the would-be private
child in the currently shared generic body, possibly rearrange the code ordering in that body so
that only the - already separate - units that actually need it see it and provide a "null'd out" separate
implementation for the system variants that do not at all need the functionality of the would-be
child unit. That "jumping through hoops" is somewhat distasteful to me and I think _might_ be made
avoidable in the future with a language rule change - _unless_ I am not appreciating some problem
which I expect that a language lawyer would be able to ?easily? point out.)

On Thursday, April 29, 2021 at 12:20:07 PM UTC+2, Vincent Marciante wrote:
>
> (My specific need is in trying to keep down code duplication in a few different implementations
> of a generic package: separate body parts/files for each different implementation appear in different
> subdirectories and the build system picks the correct ones depending on the variant being built.

So what you want is a separate package/procedure/function:

generic
package Generic_Foo is
procedure Bar;
end Generic_Foo;

--

package body Generic_Foo is
Name : String := "generic Foo";

package Baz is
procedure Qux;
end Baz;

package body Baz is separate; -magic!

procedure Bar is
begin
Baz.Qux;
end Bar;
end Generic_Foo;

--

with Ada.Text_IO;
separate(Generic_Foo)
package body Baz is
procedure Qux is
begin
Ada.Text_IO.Put_Line("Separate body of " & Name);
end Qux;
end Baz;

(Sorry in advance for google messing up indentation/formatting)

On Thursday, April 29, 2021 at 7:02:02 AM UTC-4, ehh.p...@gmail.com wrote:
> On Thursday, April 29, 2021 at 12:20:07 PM UTC+2, Vincent Marciante wrote:
> >
> > (My specific need is in trying to keep down code duplication in a few different implementations
> > of a generic package: separate body parts/files for each different implementation appear in different
> > subdirectories and the build system picks the correct ones depending on the variant being built.
> So what you want is a separate package/procedure/function:
>
> generic
> package Generic_Foo is
> procedure Bar;
> end Generic_Foo;
>
> --
>
> package body Generic_Foo is
> Name : String := "generic Foo";
>
> package Baz is
> procedure Qux;
> end Baz;
>
> package body Baz is separate; -magic!
>
> procedure Bar is
> begin
> Baz.Qux;
> end Bar;
> end Generic_Foo;
>
> --
>
> with Ada.Text_IO;
> separate(Generic_Foo)
> package body Baz is
> procedure Qux is
> begin
> Ada.Text_IO.Put_Line("Separate body of " & Name);
> end Qux;
> end Baz;
>
>
> (Sorry in advance for google messing up indentation/formatting)

That is pretty much what I have to do except that in my situation
your procedure Bar would also be separate - and that makes the big
difference: If private non-generic units were allowed (and visible
only from the body of the parent generic) then the spec of your Baz
package would not have to be declared in the body of Generic_Foo;
it would be with'd only by the body of Bar (and any other separate
that require it - without any additional declaration order requirements
in the body of Generic_Foo.

The situation would be worse if procedure Quz needed to have a
parameter whose type was not from a package that was already visible
to Genereic_Foo, forcing that package to be with'd in the body of
Generic_Foo. _And_ if the required package would then cause a chain
of dependencies to occur that are not even satisfiable in the variant
environments that do not really require it then that package wouold
also have to be dummied with null or exception-propagating subprograms.

All of that could be avoided in a simple way if use of a private child
unit as I have describe was made legal.

So what you want is an implicit instantiation as outlined below:

generic
package Gen is
end Gen;
package body Gen is
procedure Proc is separate;
end Gen;

private package Gen.Priv is -- will be implicitly instantiated
end Gen.Priv;

with Gen.Priv;
separate (Gen)
procedure Proc is
begin
...Priv.XXX... -- anything from Priv
end Proc;

This is not very far from the solution given by ehh.

On Thursday, April 29, 2021 at 1:43:52 PM UTC-4, AdaMagica wrote:
> So what you want is an implicit instantiation as outlined below:
>
> generic
> package Gen is
> end Gen;
> package body Gen is
> procedure Proc is separate;
> end Gen;
>
> private package Gen.Priv is -- will be implicitly instantiated
> end Gen.Priv;
>
> with Gen.Priv;
> separate (Gen)
> procedure Proc is
> begin
> ...Priv.XXX... -- anything from Priv
> end Proc;
>
> This is not very far from the solution given by ehh.

I see that you got what I was describing by what you presented in your
example (and yes, not very far from that of ehh) but I'm not sure that
"implicit instantiation" would be the best way to describe it. I'll think about it.

Vincent Marciante schrieb am Donnerstag, 29. April 2021 um 21:29:12 UTC+2:
> but I'm not sure that
> "implicit instantiation" would be the best way to describe it. I'll think about it.

It must be. As Gen.Priv, it has direct visibility to its parent Gen, as a private child also in its parent's private part.
When Gen is instantiated, say as Inst, Gen.Priv cannot have visibility into Inst. So the separate Proc must become

with Inst.Priv;
separate (Inst)
procedure Proc is
begin
....Priv.XXX... -- anything from Priv
end Proc;

In article <076b95b5-ff44-4c47-9b0b-50d4546c589bn@googlegroups.com>,
AdaMagica <christ-usch.grein@t-online.de> wrote:

> Vincent Marciante schrieb am Donnerstag, 29. April 2021 um 21:29:12 UTC+2:
> > but I'm not sure that
> > "implicit instantiation" would be the best way to describe it. I'll think
> > about it.
>
> It must be. As Gen.Priv, it has direct visibility to its parent Gen, as a
> private child also in its parent's private part.
> When Gen is instantiated, say as Inst, Gen.Priv cannot have visibility into
> Inst.

isn't it possible to consider that when a child is called from within
the generic parent, it must be called from an instantiation of it,
and then it's not needed to re-do the instantiation within the generic
parent?

it could be a rule that works even when the chils is public, but of
course, the instantiation could be avoided only when it is called from
within the generic parent, not when it is called from outside.

--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/

https://www.delhimazza.com/
https://www.delhimazza.com/noida-call-girl-and-escort/
https://www.delhimazza.com/gurgaon-call-girl-and-escort/
https://www.delhimazza.com/2022/03/18/delhi-escorts/
https://www.delhimazza.com/2022/03/17/call-girls-in-aerocity/
https://www.delhimazza.com/2022/03/13/noida-call-girls/
https://www.delhimazza.com/2022/03/13/gurgaon-escorts-service/
https://www.delhimazza.com/2022/03/13/noida-escort-service/
https://www.delhimazza.com/2022/03/12/delhi-call-girls/
https://www.delhimazza.com/2021/04/05/call-girl-justdial-phone-number-delhi/