Re: default formal parameters in generic declarations

[Georg Bauhaus <rm.tsoh.plus-bug.bauhaus@maps.futureapps.de>]

Eric Hughes wrote:

> Even with just two layer of instantiation this is feasible, but, in
> the phrase I used earlier, "horribly klunky" (particularly with non-
> linear references).  So here's the biggest problem: You cannot get
> simultaneously both arbitrarily deep layering and concision in formal
> parameters for ordinary usage.

By way of speculation, can nesting, to the extent it is absent from C++,
lead to at least a partial solution of this problem?

package News4 is

   type Performance_Tuning is interface;

   function Null_Tuning return Performance_Tuning'Class;

   generic
      Tuner: Performance_Tuning'Class := Null_Tuning;
   package B is

      generic
         Tuner: Performance_Tuning'Class := B.Tuner;
      package A is end;

   end B;

end News4;


To some extent, this view would require building software with "towers"
of building blocks in mind, rather than patterns of cobblestone, so to
speak.


> As a coda, I wish to add that this practice is not hypothetical.  The
> sophistication of some of the generic (template) programming in the
> Boost C++ library is excellent and worth imitating.

Again by way of speculation, and as an example, the Boost
parsing facilities have a counterpart in Ada that just works
differently, using access to nested functions.
GNAT.Spitbol.Patterns solves the same practical problems
as the spirit parsers, and more. There might be a small
overhead because pattern construction does not occur at
compile time, but then Spitbol.Patterns is actually more powerful.

I'm noting all this only because I should think there is some value
in nesting that, just maybe, is easily overlooked.