Let me just give my general thinking on this subject. I think formal
packages should be used sparingly, in part because they complicate the use
of a generic package (the more instances and parameters that you have write
before anything useful can be done, the harder it is to understand and the
more likely that you will just forget using the generic and "roll your
own").

Typically, when I've had to compose generics, I will nest an instantiation
of one inside the other. (That's pretty much all you could do in Ada 83,
after all.) Most of the time, that works fine, and the operations in the
instance can be used directly or re-exported with renames as needed.

I also would have to agree with Dmitry (at least to a point) that generics
can really interfere with your designs, so you need to use them sparingly.
You can't avoid them completely when designing something like containers
(for instance), but note that we made a strong effort to preserve the
"single instance" model in almost all of the language-defined generics. We
did that even at the cost of being able to have container interfaces (which
would be really nice for abstraction purposes, but would require a second
level of generic instances in order to be useful).

As Robert Dewar says, incompatibilities have a very high bar. There has to
be real and compelling value for an incompatibility. I don't see that in
this case that that it not clear that the revised situation is really better
than the current one -- it's mostly a sideways move.

The point is then not about the possibility to hide or the possibility
to show (that is solved), and rather about the required trick on the
name.

Always interesting, the places comp.lang.ada gets to :).

Sacrebleu!

How does look the hierarchy matrix of?

This requires a bit explanation. A set of generics sharing some common
parameter (like the number type in a generic matrix package) are kind of
class, i.e. they declare sets of types dependant on the parameter (like
vector, matrix etc). I call this almost "trivial".

Non-trivial it becomes when you have several such axes.

Here is an example of a mesh of generic packages with 4 axes:

   http://www.dmitry-kazakov.de/ada/fuzzy.htm#8

Note that semantically the example is quite simple, almost evident. Its
implementation and use is horrific. I would never consider it "fixed".

As for being the "best language feature", I hope that you would easily find
lots of more useful and advanced Ada features. What about unconstrained
types? User-defined numeric types? Packages (vs. types) as encapsulation
modules? If any of these were removed it would not be Ada. On the contrary,
Ada without generics sounds quite plausible to me.

Note : and in that case, this may be useful to make this package
visible from the outside (exporting the content via renames and
subtype, is not always done exhaustively)

You may also understand you can have generics dealing with generics,
when you use the Mixin pattern to add features in a well designed way,
to that if you ever modify the Mixin package, then modifications
applies to all the package created with this Minxin. The Mixin may be
generic, and the package it receives as a parameter as well.

Note that a generic child package can use formals of its parent. That is
the case why your proposal about visibility is so important in my eyes. It
is an *obvious* language bug.

The case is represented here:

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

generic
package P.Q is
   Y : T;
end P.Q;

with P.Q;
generic
   with package PQ is new P.Q (<>);
package R is
   X : PQ.T; -- Wring! You cannot see T, and there is no way to name it
end R;

In R you see Y of a "non-existent type".  This is obviously broken to me.

(Yes, I am extensively using the trick of subtype and renaming formal
parameters you wrote about earlier)

But as I said, generics are broken per their nature. With the time it gets
only worse. (:-()

You'll have to download and unpack the code; my webserver doesn't have
enough space for the unpacked HTML version (guess it's time to spend
more money on the web server).

There are problems that can't be solved in Ada; that doesn't make Ada
useless!

Problems that can be almost solved, and push the boundaries of the
language, and be very frustrating.

In previous months, it's been tasking, dispatching, interfaces, and
rep clauses on packed record types.

Distinct numeric types (derived from compiler defined types) is important.

Even C++ has that now. Not called packages, but close enough.

Although related by derivation, my packages were all along each others
(I'm experimenting, so I try many things before I choose and know
why). I've started to rework all package, to use child package when
possible.

It seems it saves a lot to do so : shared generic parameters, so less
generic parameters needed for instantiation.

I would like to say I feel (from higher to lower importance) child are
nice for :
1) Shared privates subset (formally required)
2) Generics (not formally required, but may save a lot of stuff)
3) Mapping domain organization (nice, but not really required,
although useful)
?) I'm still wondering about child packages and derivations (another
subject opened about it).

generic
   type T is private;
   with function "+" (Left, Right : T) return T;
package Generic_Interface is
   -- No own declarations, the package promotes its formal parameters
   -- to other packages
end Generic_Interface;

with Generic_Interface;
generic
   with package Parameters is new Generic_Interface (<>);
package P is
   -- Here we can define some further operations on Parameters.T and
   -- other types based on Parameters.T
end P;

1. one of the generic packages
2. of the instances of generic packages (you can instantiate a generic
child of generic A as a non-generic child of non-generic B)
3. of nested packages (you can instantiate within a package)

A creative use of 1-3 may create a perfect mess out of your program...

I see at least three productive enough mess seeds with generic child
hierarchy (from the less to the most nasty)
1) The implicit with which comes with all child packages, generic or
not (I had never really enjoyed this implicit With).
2) The miss-match between the generic Withed path and the actual
instance matching path
3) The naming nightmare which comes while creating the instance
hierarchy

With more details :
1) Dependencies are clearly explicit with classic packages, this is no
more the case with child packages. I know this is the same with non-
generic, but this is not really welcome to me (I sometime dream about
child packages hierarchy which would require explicit With).
2) Let A, a generic package, B, a generic child of A, C, an instance
of A, then instantiating C.B requires to With A.B. I understand why it
is this way (although this could have been another way too), but an
A.B whose A actually and implicitly match C, does not help to be
clear.
3) The one I really do not like : with same packages as in #2,
instantiating A.B as a child of C, requires to use a new name which
cannot be B, and if the name B is the most natural one in the context
of A, this mostly mean this would be the same in the context of C,
thus the naming nightmare. For the purpose of the comment which will
follows right after, let call it D.

To reword what you were saying, there is indeed three hierarchies and
not two : the source generic hierarchy (like A.B), the instance
hierarchy (like C.D) and beside this instance hierarchy, another
implicit generic hierarchy (like C.B), and this is hard to deal with.

Yes, now I'm sure you were really talking about mess.

#3 may be solved using a standard prefix for all generics, like
Generic_, but I do not like it, because this easily ends in too much
long paths. Now I'm seeking for a more clever way to easily handle
this three-hierarchies structure. This would not Solve #2 any way.

If anything has to have a separate name space then generics is the first
candidate. Generic unit is not a unit, it is a macro, a term of the meta
language. There is no reason to have it also a proper name in the object
language. The object language does not operate it. This is comparable to
the names of the "cut" and "paste" buttons in the IDE. Why an integer
variable may not have the same name as the "paste" button? (:-))

BTW, Generic_ becomes quite obtrusive with children packages. When you
have:

   generic
      ...
   package Generic_Grandfather.Geneirc_Father.Generic_Son is

you start to think who is a generic_idiot here? (:-))

The problem of naming is only of a facet of the bigger mess. It is a
consequence of a bad pattern, but that pattern is imposed by the language.

Maybe such common patterns could be classified and given recognizable
suffixes or prefixes instead of rather empty Generic_, which adds no value
beyond merely separating the name space.