A small blog post that you might find interesting:

https://deepbluecap.com/calling-inherited-primitive-operations-in-ada/

We are preparing a number of other posts, but right now this is the only one on our web site, so the links are a bit hidden. They will become available on https://deepbluecap.com/blog/ as we publish them.

Emmanuel

Le 31/08/2022 à 10:15, Emmanuel Briot a écrit :
> A small blog post that you might find interesting:
>
> https://deepbluecap.com/calling-inherited-primitive-operations-in-ada/
>
> We are preparing a number of other posts, but right now this is the only one on our web site, so the links are a bit hidden. They will become available on https://deepbluecap.com/blog/ as we publish them.
>
> Emmanuel

That's interesting.

You should compile all excerpts of code you publish. This will avoid
typos like "Polgyon" ;)

Nicolas

On 2022-08-31 10:15, Emmanuel Briot wrote:
> A small blog post that you might find interesting:
>
> https://deepbluecap.com/calling-inherited-primitive-operations-in-ada/

This same technique is used in generics to work around another language
design "feature":

generic
type Foo is ...;
package
subtype Actual_Foo is Foo;

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

> generic
> type Foo is ...;
> package
> subtype Actual_Foo is Foo;

To me, this is an orthogonal issue though (which would be worth its own blog post in fact). I can never remember (or perhaps not even understand) the reason for this limitation in Ada, which is a major pain when dealing with generics indeed...
I like the "Actual_" prefix, which I assume is some sort of convention in your code.

Emmanuel

On Thursday, September 1, 2022 at 8:56:28 AM UTC+2, briot.e...@gmail.com wrote:
> > generic
> > type Foo is ...;
> > package
> > subtype Actual_Foo is Foo;
> To me, this is an orthogonal issue though (which would be worth its own blog post in fact). I can never remember (or perhaps not even understand) the reason for this limitation in Ada, which is a major pain when dealing with generics indeed...
> I like the "Actual_" prefix, which I assume is some sort of convention in your code.

Is this about how according to some mystifying rules generic formals are[n't] visible from outside the generic?

On 2022-09-01 09:57, amo...@unizar.es wrote:
> On Thursday, September 1, 2022 at 8:56:28 AM UTC+2, briot.e...@gmail.com wrote:
>>> generic
>>> type Foo is ...;
>>> package
>>> subtype Actual_Foo is Foo;
>> To me, this is an orthogonal issue though (which would be worth its own blog post in fact). I can never remember (or perhaps not even understand) the reason for this limitation in Ada, which is a major pain when dealing with generics indeed...
>> I like the "Actual_" prefix, which I assume is some sort of convention in your code.
>
> Is this about how according to some mystifying rules generic formals are[n't] visible from outside the generic?

Right. I do not remember the rules, just the fact that they are quite
logical. Unfortunately the logic of is not very helpful. (:-))

As for primitive operations the problems are on many levels, from
lacking introspection to missing inheritance of implementation by
composition (AKA hooking).

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

On 2022-09-01 09:57, amo...@unizar.es wrote:
>
> Is this about how according to some mystifying rules generic formals are[n't] visible from outside the generic?

This seems like a non-issue to me. Any code that has visibility to a generic
instance knows the actuals used for that instance. Can anyone provide real
examples where this is a problem?

--
Jeff Carter
"[M]any were collected near them, ... to
enjoy the sight of a dead young lady, nay,
two dead young ladies, for it proved twice
as fine as the first report."
Persuasion
155

On 2022-09-01 13:59, Jeffrey R.Carter wrote:
> On 2022-09-01 09:57, amo...@unizar.es wrote:
>>
>> Is this about how according to some mystifying rules generic formals
>> are[n't] visible from outside the generic?
>
> This seems like a non-issue to me. Any code that has visibility to a
> generic instance knows the actuals used for that instance.

That would make the code fragile. Should be avoided as much as possible
as a form of aliasing. Compare:

procedure A (X : Integer) is
procedure B (Y : Integer) is
begin
X := 1; -- We know we are going to call it with X!
end B;
begin
B (X);
end A;

> Can anyone
> provide real examples where this is a problem?

Defaulted formal package actual part:

generic
package Foo is new Bar (<>);
package Baz is ...
-- What were these actuals in Foo?

This is one of most useful features used to reduce lists of formal
parameters and simplify instantiations.

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

On 2022-09-01 14:37, Dmitry A. Kazakov wrote:
>

Toy problem ignored.

>> Can anyone provide real examples where this is a problem?
>
> Defaulted formal package actual part:
>
>    generic
>       package Foo is new Bar (<>);
>    package Baz is ...
>       -- What were these actuals in Foo?

1. The actuals of Foo are visible within Baz.
2. This is not a real example.
3. You have changed the subject from needing to rename a formal type. I presume
this is because there are no real examples where renaming a formal type in an
instance is needed.

--
Jeff Carter
"[M]any were collected near them, ... to
enjoy the sight of a dead young lady, nay,
two dead young ladies, for it proved twice
as fine as the first report."
Persuasion
155

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.

Here is a quick example and the corresponding compiler error message. In Main, there is no way to see T. Of course, I can use Integer_Signature
directly, but this is an issue.
- if I rename Integer_Signature then I have to change a lot of places in my code (The aliasing that Dmitry was talking about)

with Signature;
generic
with package Sign is new Signature (<>);
package Algo is
procedure Compute (V : Sign.T) is null;
end Algo;

with Algo;
with Signature;
package Lib is
package Integer_Signature is new Signature (Integer);
package Integer_Algo is new Algo (Integer_Signature);
end Lib;

with Lib;
procedure Main is
V : Lib.Integer_Algo.Sign.T;
-- main.adb:3:24: "Sign" is not a visible entity of "Integer_Algo"
begin
null;
end Main;

generic
type T is private;
package Signature is
end Signature;

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.
>>>

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.
> >>>

On 2022-09-01 16:10, Emmanuel Briot 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.

None of these deal with the example I responded to

generic
type T is ...
package P is
subtype Actual_T is T;

> Reason: {AI05-0005-1} We always want either the actuals or the formals of an instance to be nameable from outside, but never both.
This is true in all these examples. I have used Ada since 1984, and this has
never been a problem for me (as initially presented, this would have existed in
Ada 83). Of course, I generally avoid generic formal pkgs. They seem to me to be
a work around for poor design, and I prefer to correct the design.

--
Jeff Carter
"[M]any were collected near them, ... to
enjoy the sight of a dead young lady, nay,
two dead young ladies, for it proved twice
as fine as the first report."
Persuasion
155

On Thursday, September 1, 2022 at 6:03:22 PM UTC+2, Jeffrey R.Carter wrote:
> This is true in all these examples. I have used Ada since 1984, and this has
> never been a problem for me (as initially presented, this would have existed in

So basically saying that you do not use generics (or only very basic versions) and you have never seen
the bug that relates to complex generics. Not very useful input ?
For sure, that's already a number of persons who have said they have seen this bug a number of times.
I have of course only been using Ada for 25 years, but that sure was enough to see that issue...

On 2022-09-01 18:07, Emmanuel Briot wrote:
>
> So basically saying that you do not use generics (or only very basic versions) and you have never seen
> the bug that relates to complex generics. Not very useful input ?

I have not said this. I have worked on very large problems and on generics
appropriate to such problems. Of course, KISS is an important S/W-eng principle.

--
Jeff Carter
"[M]any were collected near them, ... to
enjoy the sight of a dead young lady, nay,
two dead young ladies, for it proved twice
as fine as the first report."
Persuasion
155

I think I have a more interesting example. This one is extracted from my attempted traits containers, for which I had published a blog post at AdaCore.. My enhanced fork of the library is at
https://github.com/briot/ada-traits-containers
if someone wants to experiment with non-trivial generics code (and containers are of course a case where generics fully make sense).

Here is the example:

generic
type Element_Type is private;
type Stored_Type is private;
package Elements is
end Elements;

with Elements;
generic
type Element_Type is private;
package Definite_Elements is
package Traits is new Elements (Element_Type, Stored_Type => Element_Type);
end Definite_Elements;

with Definite_Elements;
generic
type Key_Type is private;
package Maps is
package Keys is new Definite_Elements (Key_Type);
function "=" (L, R : Keys.Traits.Stored_Type) return Boolean -- "Stored_Type" is not a visible entity of "Traits"
is (False);
end Maps;

This is not case where the actual is visible unless I happen to know how Definite_Element is implemented and that it will use Element_Type for Stored_Type (and this is not a knowledge I wish client packages to have, the whole point of Element and Definite_Element is to basically hide how elements can be stored in a container, and whether we need memory allocation for instance).

On 2022-09-01 20:54, Emmanuel Briot wrote:
>
> generic
> type Element_Type is private;
> type Stored_Type is private;
> package Elements is
> end Elements;
>
> with Elements;
> generic
> type Element_Type is private;
> package Definite_Elements is
> package Traits is new Elements (Element_Type, Stored_Type => Element_Type);
> end Definite_Elements;
>
> with Definite_Elements;
> generic
> type Key_Type is private;
> package Maps is
> package Keys is new Definite_Elements (Key_Type);
> function "=" (L, R : Keys.Traits.Stored_Type) return Boolean -- "Stored_Type" is not a visible entity of "Traits"
> is (False);
> end Maps;

As presented, this seems very over complicated. Elements and Definite_Elements
add no value, and this is just a complex way of writing

generic
type Key is private;
package Maps is
function "=" (L : in Key; R : in Key) return Boolean is (False);
end Maps;

One hopes that the actual library makes better use of these pkgs than this small
example.

> This is not case where the actual is visible unless I happen to know how Definite_Element is implemented and that it will use Element_Type for Stored_Type (and this is not a knowledge I wish client packages to have, the whole point of Element and Definite_Element is to basically hide how elements can be stored in a container, and whether we need memory allocation for instance).

Ada has excellent features for hiding, but these are not among them. Assuming
that pkg Keys serves some actual role in the spec of Maps, then someone wanting
to use pkg Maps will need to understand that role, which involves understanding
Definite_Elements, which involves understanding pkg Traits, which involves
understanding Elements. Rather than hiding anything, you are effectively
requiring your users to look at these things, even if you could use the notation
in question.

--
Jeff Carter
"[M]any were collected near them, ... to
enjoy the sight of a dead young lady, nay,
two dead young ladies, for it proved twice
as fine as the first report."
Persuasion
155

> As presented, this seems very over complicated. Elements and Definite_Elements
> add no value, and this is just a complex way of writing

I did point you to the full repository if you prefer an extensive, real-life code sample. This was just an extract showing the gist of the issue.

> One hopes that the actual library makes better use of these pkgs than this small
> example.

One can check the full code and extensive documentation on the design in the github repository.
This is called code reuse, was invented quite a while ago.
These packages are mostly implementation details. They are used to build high-level packages similar to the Ada containers, except with much better code reuse, more efficient, and SPARK-provable.

> Ada has excellent features for hiding, but these are not among them. Assuming

And that's exactly our point in this discussion. Ada on the whole is very good (we would not be using it otherwise), but it does have a number of limitations which are sometimes a pain, this being one of them. Not acknowledging the limitations when they exist is naive, all languages have them.

> that pkg Keys serves some actual role in the spec of Maps, then someone wanting
> to use pkg Maps will need to understand that role, which involves understanding
> Definite_Elements, which involves understanding pkg Traits, which involves
> understanding Elements.

which involves understanding Ada, which involves understanding the compiler, which involves understanding the kernel sources, ...
How many times have you checked the whole sources of the GNAT runtime to understand how they implemented the Ada containers ?

Emmanuel

On Thursday, September 1, 2022 at 11:33:47 PM UTC+2, Jeffrey R.Carter wrote:
> On 2022-09-01 20:54, Emmanuel Briot wrote:

> As presented, this seems very over complicated. Elements and Definite_Elements
> add no value, and this is just a complex way of writing

Going in a tangent, and I guess you know perfectly well, but this is caused by the painful duplication of code that Ada pushes you to by not having a native way to abstract storage of definite vs indefinite types. So the provider of a generic library very soon faces this conundrum about duplicating most interfaces, if not implementations, or resort to non-trivial generics, or accept an unnecessary penalty for definite types, or push to the client the definite storage matter. There's simply no satisfying solution here [that I know of]. The duplication of every standard container to have both [in]definite variants is a strong indictment.

I can understand the desire to have full control of allocation and object sizes, but that there's not a language way to work around this duplication, with appropriate restrictions to go with it, is... bothersome. Not making a dig at the ARG, which I understand is overstretched as it is.

There was a proposal circulating some time ago that seemed promising, that I can't quickly find. Something like

type Blah is record
Dont_care_if_in_heap: new Whatever_Definiteness; -- Would apply to indefinite types or formals
end record;

I don't think it made into https://github.com/AdaCore/ada-spark-rfcs/ or https://github.com/Ada-Rapporteur-Group/User-Community-Input/issues or I can't find it.

On 2022-09-02 10:35, amo...@unizar.es wrote:
> On Thursday, September 1, 2022 at 11:33:47 PM UTC+2, Jeffrey R.Carter wrote:
>> On 2022-09-01 20:54, Emmanuel Briot wrote:
>
>> As presented, this seems very over complicated. Elements and Definite_Elements
>> add no value, and this is just a complex way of writing
>
> Going in a tangent, and I guess you know perfectly well, but this is caused by the painful duplication of code that Ada pushes you to by not having a native way to abstract storage of definite vs indefinite types. So the provider of a generic library very soon faces this conundrum about duplicating most interfaces, if not implementations, or resort to non-trivial generics, or accept an unnecessary penalty for definite types, or push to the client the definite storage matter. There's simply no satisfying solution here [that I know of]. The duplication of every standard container to have both [in]definite variants is a strong indictment.
>
> I can understand the desire to have full control of allocation and object sizes, but that there's not a language way to work around this duplication, with appropriate restrictions to go with it, is... bothersome. Not making a dig at the ARG, which I understand is overstretched as it is.

Containers should be implementable without generics. Just saying.

> There was a proposal circulating some time ago that seemed promising, that I can't quickly find. Something like
>
> type Blah is record
> Dont_care_if_in_heap: new Whatever_Definiteness; -- Would apply to indefinite types or formals
> end record;

I would prefer constraint propagation/management support + tuples instead:

type Blah (Parameters : Whatever_Definiteness'Constraints) is
Sill_Care : Whatever_Definiteness (Parameters);
end record;

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

On Friday, September 2, 2022 at 10:48:57 AM UTC+2, Dmitry A. Kazakov wrote:

> Containers should be implementable without generics. Just saying.

Are you now referring to current Ada or to hypothetical features?

> I would prefer constraint propagation/management support + tuples instead:
>
> type Blah (Parameters : Whatever_Definiteness'Constraints) is
> Sill_Care : Whatever_Definiteness (Parameters);
> end record;

Whatever ;-) as long as it's an effective solution.

On 2022-09-02 11:20, amo...@unizar.es wrote:
> On Friday, September 2, 2022 at 10:48:57 AM UTC+2, Dmitry A. Kazakov wrote:
>
>> Containers should be implementable without generics. Just saying.
>
> Are you now referring to current Ada or to hypothetical features?

Hypothetical like all types having classes and supertypes. E.g. when you
instantiate generic with a type you semantically place the type in the
implicit class of formal types of the generic. You cannot do that now
without generics. Furthermore, there is no way to describe relationships
between types like array index and array, like range and discrete type
of its elements etc.

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

On 2022-09-02 10:35, amo...@unizar.es wrote:
>
> Going in a tangent, and I guess you know perfectly well, but this is caused by the painful duplication of code that Ada pushes you to by not having a native way to abstract storage of definite vs indefinite types. So the provider of a generic library very soon faces this conundrum about duplicating most interfaces, if not implementations, or resort to non-trivial generics, or accept an unnecessary penalty for definite types, or push to the client the definite storage matter. There's simply no satisfying solution here [that I know of]. The duplication of every standard container to have both [in]definite variants is a strong indictment.

The only indefinite data structure that is needed seems to be holders. Any other
indefinite data structure can be implemented as the equivalent definite data
structure of holders, so there need be no duplication of implementations. That
one cannot use a single pkg for both does result in duplication of the spec, but
that seems like less of an issue to me.

--
Jeff Carter
"Apple juice and Darvon is fantastic together."
Play It Again, Sam
127

On 2022-09-02 08:11, Emmanuel Briot wrote:
>
> I did point you to the full repository if you prefer an extensive, real-life code sample. This was just an extract showing the gist of the issue.
>
> One can check the full code and extensive documentation on the design in the github repository.

Yes, I looked at it, and found it over complicated, difficult to understand, and
not user friendly. There appears to be extensive HTML documentation, but it can
only be viewed as HTML source in Github, which is not easy to read, so I didn't.

Apparently a user who wants a map has to supply a significant part of what I
consider the implementation of the map. As such, this may serve as a hidden
layer to implement a library of data structures, but seems unusable for the
typical user, for whom using a hashed-map abstraction should be as simple as

function Hash (Key : in Identifier) return Hash_Value;

package Maps is new Lib.Maps
(Identifier => Identifier, Associated_Value => Associated_Value);

I was not willing to spend more than about 15 minutes trying to understand this,
so I may be missing something.

> These packages are mostly implementation details. They are used to build high-level packages similar to the Ada containers

This agrees with what I was saying earlier. But even for such a use, simplicity
and ease of understanding are still the most important aspects of S/W. If
attaining them involves some code duplication they are worth that price.

>> that pkg Keys serves some actual role in the spec of Maps, then someone wanting
>> to use pkg Maps will need to understand that role, which involves understanding
>> Definite_Elements, which involves understanding pkg Traits, which involves
>> understanding Elements.
>
> which involves understanding Ada, which involves understanding the compiler, which involves understanding the kernel sources, ...
> How many times have you checked the whole sources of the GNAT runtime to understand how they implemented the Ada containers ?

One understands a pkg by understanding its spec. I find it hard to believe that
you could actually think that I meant one had to understand the implementation
as well.

--
Jeff Carter
"Apple juice and Darvon is fantastic together."
Play It Again, Sam
127

On 2022-09-02 12:41, Jeffrey R.Carter wrote:

> The only indefinite data structure that is needed seems to be holders.

The language should support and encourage design that does not rely on
memory pools.

In my view one of major advantages of Ada is that indefinite objects can
be handled without resorting to hidden or explicit pointers to pools.

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

> not user friendly. There appears to be extensive HTML documentation, but it can
> only be viewed as HTML source in Github, which is not easy to read, so I didn't.

Those are generated from the .rst files in docs_src/

> typical user, for whom using a hashed-map abstraction should be as simple as
>
> function Hash (Key : in Identifier) return Hash_Value;
> package Maps is new Lib.Maps
> (Identifier => Identifier, Associated_Value => Associated_Value);

Maps are created as

package Maps0 is new GAL.Maps.Def_Def_Unbounded
(Integer,
Element_Type => Integer,
Hash => Test_Support.Hash,
Container_Base_Type => GAL.Controlled_Base);

The only addition here is `Container_Base_Type`, and that's because the library is probable with SPARK, and the latter doesn't support controlled types.
And Ada doesn't support default values for the formal parameters of generics (another annoying limitation !)

> I was not willing to spend more than about 15 minutes trying to understand this,
> so I may be missing something.

Fair enough. The library is really a set of experiments, mostly successful, and I think it might have been used for the implementation of the current
SPARK containers in GNAT, though I am not positive there.
I did look at the pragmARC components, and there you indeed chose to have a large number of similar-looking packages and code duplication. I guess
we'll have just to agree to disagree on the design approach there. But of course, users having choices is what makes an ecosystem interesting.

What I was really going after are graphs and their algorithms. In particular, I want those algorithms to work on any graph data structure provided it has
a number of primitive operations. In fact, the algorithm could also work when the graph is kind of implicit in the code, even if we do not have an actual
Graph object. And those this, you need generics.

A similar approach is what Rust uses all over the place with its traits, or what C++ Boost library uses for its graphs, too.