Re: Access to generic formal parameters in an generic package instantiation

[Florian Weimer <fw@deneb.enyo.de>]

* Dmitry A. Kazakov:

> On Sun, 29 Jul 2012 20:16:00 +0200, Florian Weimer wrote:
>
>> If G is a generic package and P is one of its formal parameters, it is
>> legal to refer to G.P where G is visible?  Does this depend on the
>> kind of entity, or whether the formal part uses <>?
>
> Sometimes it works, sometimes it does not, I am not a language lawyer to
> tell when GNAT is right or not.

It seems that the names of the generic formal declarations are lost
except if they refer to implicit declaration (those using <>).  I'm
not sure why implicit declarations are special-cased like this.  There
is sometimes no way to reference to an implicit declaration because
you are not supplying the arguments.  But if you want to get the
arguments back reliably, you have to add declarations anyway, and
those cover the implicit case as well, so I'm not sure this language
feature is really necessary.

> Facing this problem quite frequently, I developed a custom to rename
> formal parameters within the declaration area, e.g.
>
> generic
>    type Foo is ...;
>    with package Bar is new Baz (<>);
> package Boo is
>    subtype My_Foo is Foo;
>    package My_Bar is renames Bar;
>    ...

The same approach is used in C++ where template arguments are not
accessible from outside of the template.  Instead, you have to provide
typedefs for alias names.

> Another method of making formal parameters visible is to have it a
> generic child.

This smells a bit like a compiler bug.  The standard doesn't seem to
mention it.

>> that is, specify that two types in two formal packages are the same,
>> without break down the formal packages to their components?
>
> Yes. There several techniques to accomplish this.
>
> 1. You can to make that type a formal parameter and specify it among the
> formal parameters of the instances:
>
>    type T is ...
>    with package P1 (T, <>);
>    with package P2 (T, <>);

I got a bug box when I tried this.

> Though you likely won't believe me anyway, but using generics is a very bad
> idea unless absolutely nothing else works. Here is an outlook what it
> becomes in a relatively simple case:
>
>    http://www.dmitry-kazakov.de/ada/fuzzy_packages.gif

It's just the usual curse of the higher order.  Functions call graphs
aren't always pretty, either.

Anyway, I'm trying to find a good way for resource management which
does not rely on finalization, and I want to cut down boilerplate
code.