Re: Calling inherited primitive operations in Ada

["amo...@unizar.es" <amosteo@unizar.es>]

On Thursday, September 1, 2022 at 4:11:54 PM UTC+2, briot.e...@gmail.com wrote:
> I have seen quite a number of cases of needing the subtype like Dmitry was showing. In a small number of cases, those were actual bugs in GNAT, but most of the time the compiler was correct. 
> Mostly, you start to see the issue when you have generic packages that have formal generic packages. 

This matches exactly my experience. I don't have enough grasp of the details to come up with a realistic short example, but I did hit this issue pretty often in two libs were I used signature packages quite extensively:

https://github.com/mosteo/rxada
https://github.com/mosteo/iterators

Initially I was always under the impression I was hitting GNAT bugs but then it turned out there were rules about it. A couple example places (you can see the renamings at the top. I was adding them "on demand" so to say):

https://github.com/mosteo/iterators/blob/master/src/iterators-traits-containers.ads
https://github.com/mosteo/rxada/blob/master/src/priv/rx-impl-transformers.ads
 
Thanks Emmanuel for the examples and digging out Tucker explanation.

-Alex.

> There are more interesting examples, somehow this one doesn't seem that bad. So here is another one: 
> 
> generic 
> type T is private; 
> package Gen is 
> end Gen; 
> 
> with Gen; 
> generic 
> type T is private; 
> with package Must_Match is new Gen (T); 
> with package Need_Not_Match is new Gen (<>); 
> package Gen2 is 
> V1 : Must_Match.T; -- "T" is not a visible entity of "Must_Match" 
> V2 : Need_Not_Match.T; -- instance of same package, but this time T is visible 
> end Gen2; 
> 
> with Gen, Gen2; 
> procedure P2 is 
> package G is new Gen (Integer); 
> package G2 is new Gen2 (Integer, G, G); 
> begin 
> null; 
> end P2; 
> 
> 
> 
> 
> I dug out the explanation that Tucker Taft once sent to the Ada-Comment mailing list (2019-11-14): 
> 
> <<< 
> 10/2 
> {AI95-00317-01} The visible part of a formal package includes the first list of basic_declarative_items of the package_specification. In addition, for each actual parameter that is not required to match, a copy of the declaration of the corresponding formal parameter of the template is included in the visible part of the formal package. If the copied declaration is for a formal type, copies of the implicit declarations of the primitive subprograms of the formal type are also included in the visible part of the formal package. 
> 10.a/2 
> Ramification: {AI95-00317-01} If the formal_package_actual_part is (<>), then the declarations that occur immediately within the generic_formal_part of the template for the formal package are visible outside the formal package, and can be denoted by expanded names outside the formal package.If only some of the actual parameters are given by <>, then the declaration corresponding to those parameters (but not the others) are made visible. 
> 10.b/3 
> Reason: {AI05-0005-1} We always want either the actuals or the formals of an instance to be nameable from outside, but never both. If both were nameable, one would get some funny anomalies since they denote the same entity, but, in the case of types at least, they might have different and inconsistent sets of primitive operators due to predefined operator “reemergence.” Formal derived types exacerbate the difference. We want the implicit declarations of the generic_formal_part as well as the explicit declarations, so we get operations on the formal types. 
> >>>