A proposal for formal packages matching

A proposal for formal packages matching

[Dmitry A. Kazakov]

There seems one overlooked thing in the rules controlling matching formal
packages. An instance of generic child package does not match as an
instance of the generic parent.

I mean the following:

generic
package Generic_A is
end Generic_A;

package A is new Generic_A;

generic
package Generic_A.Generic_B is
end Generic_A.Generic_B;

package AB is new A.Generic_B;

generic
   with package A is new Generic_A (<>);
package Generic_Foo is
end Generic_Foo;

package Foo is new Generic_Foo (AB);
   -- Error: AB is not an instance of Generic_A

Semantically, AB being an extension of Generic_A can be considered an
instance of.

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

Re: A proposal for formal packages matching

[Ludovic Brenta]

On Dec 15, 11:21 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> There seems one overlooked thing in the rules controlling matching formal
> packages. An instance of generic child package does not match as an
> instance of the generic parent.
>
> I mean the following:
>
> generic
> package Generic_A is
> end Generic_A;
>
> package A is new Generic_A;
>
> generic
> package Generic_A.Generic_B is
> end Generic_A.Generic_B;
>
> package AB is new A.Generic_B;
>
> generic
>    with package A is new Generic_A (<>);
> package Generic_Foo is
> end Generic_Foo;
>
> package Foo is new Generic_Foo (AB);
>    -- Error: AB is not an instance of Generic_A
>
> Semantically, AB being an extension of Generic_A can be considered an
> instance of.

No, because semantically, packages are not types. They are units of
visibility. And they are orthogonal to type extension, dynamic
dispatching and object-oriented programming if that's what you have in
mind.

--
Ludovic Brenta.

Re: A proposal for formal packages matching

[Dmitry A. Kazakov]

On Mon, 15 Dec 2008 04:13:47 -0800 (PST), Ludovic Brenta wrote:

> On Dec 15, 11:21 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> There seems one overlooked thing in the rules controlling matching formal
>> packages. An instance of generic child package does not match as an
>> instance of the generic parent.
>>
>> I mean the following:
>>
>> generic
>> package Generic_A is
>> end Generic_A;
>>
>> package A is new Generic_A;
>>
>> generic
>> package Generic_A.Generic_B is
>> end Generic_A.Generic_B;
>>
>> package AB is new A.Generic_B;
>>
>> generic
>>    with package A is new Generic_A (<>);
>> package Generic_Foo is
>> end Generic_Foo;
>>
>> package Foo is new Generic_Foo (AB);
>>    -- Error: AB is not an instance of Generic_A
>>
>> Semantically, AB being an extension of Generic_A can be considered an
>> instance of.
> 
> No, because semantically, packages are not types. They are units of
> visibility. And they are orthogonal to type extension, dynamic
> dispatching and object-oriented programming if that's what you have in
> mind.

I didn't. (For that matter the concept of type extension is questionable.)

I meant exclusively visibility. A child package has parent's declaration
visible in its body.

   package Foo is new Generic_Foo (AB);

should read, "take AB or any of its parents, which is an instance of
Generic_A."

[ Presently it is insolvable in an implicit form, because the actual of the
parent package has no name. Differently to the formal parameters, which
actuals are anonymous "outside," but named "inside," parents are anonymous
for all sights. ]

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

Re: A proposal for formal packages matching

[Ludovic Brenta]

On Dec 15, 2:29 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Mon, 15 Dec 2008 04:13:47 -0800 (PST), Ludovic Brenta wrote:
> > On Dec 15, 11:21 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > wrote:
> >> There seems one overlooked thing in the rules controlling matching formal
> >> packages. An instance of generic child package does not match as an
> >> instance of the generic parent.
>
> >> I mean the following:
>
> >> generic
> >> package Generic_A is
> >> end Generic_A;
>
> >> package A is new Generic_A;
>
> >> generic
> >> package Generic_A.Generic_B is
> >> end Generic_A.Generic_B;
>
> >> package AB is new A.Generic_B;
>
> >> generic
> >>    with package A is new Generic_A (<>);
> >> package Generic_Foo is
> >> end Generic_Foo;
>
> >> package Foo is new Generic_Foo (AB);
> >>    -- Error: AB is not an instance of Generic_A
>
> >> Semantically, AB being an extension of Generic_A can be considered an
> >> instance of.
>
> > No, because semantically, packages are not types. They are units of
> > visibility. And they are orthogonal to type extension, dynamic
> > dispatching and object-oriented programming if that's what you have in
> > mind.
>
> I didn't. (For that matter the concept of type extension is questionable.)
>
> I meant exclusively visibility. A child package has parent's declaration
> visible in its body.
>
>    package Foo is new Generic_Foo (AB);
>
> should read, "take AB or any of its parents, which is an instance of
> Generic_A."
>
> [ Presently it is insolvable in an implicit form, because the actual of the
> parent package has no name. Differently to the formal parameters, which
> actuals are anonymous "outside," but named "inside," parents are anonymous
> for all sights. ]

The child's body sees its parent's private part but what does that
have to do with the generic? The generic only needs visibility into
the parent's public part. Assuming the language allowed you to pass a
child as the actual for a formal that requires a parent, what would
this buy you? If you see the child (AB) you can also see its parent
(A) so I can't think of a case where passing the parent as the actual
is a problem.

--
Ludovic Brenta.

Re: A proposal for formal packages matching

[Dmitry A. Kazakov]

On Mon, 15 Dec 2008 07:43:47 -0800 (PST), Ludovic Brenta wrote:

> The child's body sees its parent's private part but what does that
> have to do with the generic? The generic only needs visibility into
> the parent's public part.

I cannot comment on this. It is not about what a generic child needs. It is
about matching formal packages.

> Assuming the language allowed you to pass a
> child as the actual for a formal that requires a parent, what would
> this buy you?

Simplicity, no need to search for a parent. I don't see any obvious reason
why an instance of a child should not match its formal parent.

> If you see the child (AB) you can also see its parent
> (A) so I can't think of a case where passing the parent as the actual
> is a problem.

The parent can be a formal parameter of a formal parameter of a generic
package that instantiates the child in its declaration part. There existed
problems such constructs before. I cannot tell whether they were Ada 95 or
GNAT problems, and whether one cannot run into similar issues in Ada 2005.

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

Re: A proposal for formal packages matching

[Randy Brukardt]

> On Dec 15, 11:21 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> There seems one overlooked thing in the rules controlling matching formal
>> packages. An instance of generic child package does not match as an
>> instance of the generic parent.
>>
>> I mean the following:
>>
>> generic
>> package Generic_A is
>> end Generic_A;
>>
>> package A is new Generic_A;
>>
>> generic
>> package Generic_A.Generic_B is
>> end Generic_A.Generic_B;
>>
>> package AB is new A.Generic_B;

This is illegal; you need a with clause on A and on Generic_B:

with A, Generic_A.Generic_B;
package AB is new A.Generic_B;

(I'm not certain I have this exactly right; Steve Baird calls the process 
where these generics become visible as "sprouting", because it is soo weird. 
I'd preferred to have done without generic children altogether, but it's too 
late for that.)

>>
>> generic
>>    with package A is new Generic_A (<>);
>> package Generic_Foo is
>> end Generic_Foo;
>>
>> package Foo is new Generic_Foo (AB);
>>    -- Error: AB is not an instance of Generic_A
>>
>> Semantically, AB being an extension of Generic_A can be considered an
>> instance of.

This doesn't make any sense to me. AB is not an instance of Generic_A. 
Period. It's a different unit. You need to reference A here (I'm sure you 
know that). Implicitly referencing a parent unit is very weird, especially 
as you want to do so for a unit that it isn't ever clear that it has a 
parent.

Indeed, the declaration of "AB" is dubious. The intent of the language 
designers (as I best I understand it) was for these instances to also be 
children.

with Generic_A.Generic_B;
package A.B is new A.Generic_B;

in which case there wouldn't be any temptation to reference the parent 
implicitly.

                                   Randy.

Re: A proposal for formal packages matching

[Dmitry A. Kazakov]

On Mon, 15 Dec 2008 20:09:25 -0600, Randy Brukardt wrote:

> Indeed, the declaration of "AB" is dubious. The intent of the language 
> designers (as I best I understand it) was for these instances to also be 
> children.
> 
> with Generic_A.Generic_B;
> package A.B is new A.Generic_B;
> 
> in which case there wouldn't be any temptation to reference the parent 
> implicitly.

The language designers didn't articulate their intent well. If instances of
children were per "intent" children of instances, then I would expect some
equivalent of extension aggregates for instantiations of paths of generic
packages etc...

Anyway, there are two parents of a child package instance, to add
confusion, I guess. I didn't mean the "actual parent" of a child instance.
There could be none. I meant the actual of the "formal parent." (Generics
are cool, aren't they? (:-))

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