Diamond diagram for 'with'

Diamond diagram for 'with'

[Dmitry A. Kazakov]

I would ask language lawyers regarding multiple with.

Consider this:

    limited with Root.A;
    package Root is
    end Root;

    package Root.A is
       type T is ...;
    end Root.A;

    with Root.A;
    package Root.B is
    end Root.B;

Now Root.B has both limited (inherited from Root) and full "with" of 
Root.A. So, may Root.B use Root.A.T? It cannot according to "limited 
with" and it can due to full "with". Which one to win?

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

Re: Diamond diagram for 'with'

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:p6k68f$9li$1@gioia.aioe.org...
>I would ask language lawyers regarding multiple with.
>
> Consider this:
>
>    limited with Root.A;
>    package Root is
>    end Root;
>
>    package Root.A is
>       type T is ...;
>    end Root.A;
>
>    with Root.A;
>    package Root.B is
>    end Root.B;
>
> Now Root.B has both limited (inherited from Root) and full "with" of 
> Root.A. So, may Root.B use Root.A.T? It cannot according to "limited with" 
> and it can due to full "with". Which one to win?

Off the top of my head, it should be the "full with". Generally, Ada allows 
one to open more visibility, but you can't remove it. Deriving this formally 
would be somewhat painful, but it has to be true, since the motivating use 
for
limited with is something like:

    limited with P;
    package Q is
         ...
    end Q;

    limited with Q;
    package P is
        ...
    end P;

    with Q;
    package body P is
        -- Q is normally visible here.
    end P;

If the limited with "won" in the body, one could never access the full 
package in the body, which would make actually implementing any mutually 
dependent package hard. (You may want to call some primitive routine 
declared in Q in the body of P, but that isn't possible for a "limited 
with").

Since all withs work basically the same way, the same has to be true for a 
child package.

BTW, Root.A.T would be legal either way. But if it came from the limited 
with, it would be an incomplete type (which has its own limitations).

                                Randy.

Re: Diamond diagram for 'with'

[Dmitry A. Kazakov]

On 22/02/2018 02:38, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:p6k68f$9li$1@gioia.aioe.org...
>> I would ask language lawyers regarding multiple with.
>>
>> Consider this:
>>
>>     limited with Root.A;
>>     package Root is
>>     end Root;
>>
>>     package Root.A is
>>        type T is ...;
>>     end Root.A;
>>
>>     with Root.A;
>>     package Root.B is
>>     end Root.B;
>>
>> Now Root.B has both limited (inherited from Root) and full "with" of
>> Root.A. So, may Root.B use Root.A.T? It cannot according to "limited with"
>> and it can due to full "with". Which one to win?
> 
> Off the top of my head, it should be the "full with". Generally, Ada allows
> one to open more visibility, but you can't remove it. Deriving this formally
> would be somewhat painful, but it has to be true, since the motivating use
> for
> limited with is something like:
> 
>      limited with P;
>      package Q is
>           ...
>      end Q;
> 
>      limited with Q;
>      package P is
>          ...
>      end P;
> 
>      with Q;
>      package body P is
>          -- Q is normally visible here.
>      end P;
> 
> If the limited with "won" in the body, one could never access the full
> package in the body, which would make actually implementing any mutually
> dependent package hard. (You may want to call some primitive routine
> declared in Q in the body of P, but that isn't possible for a "limited
> with").

That is logical. A more permissive access should consume the less 
permissive one.

> Since all withs work basically the same way, the same has to be true for a
> child package.
> 
> BTW, Root.A.T would be legal either way. But if it came from the limited
> with, it would be an incomplete type (which has its own limitations).

Yes, this is how I came to this, GNAT complained about incomplete types. 
So it is possible a compiler bug, however I worked it around anyway.

I am keeping on avoiding "limited with", and the only time I lowered my 
guard, it bite me! (:-))

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

Re: Diamond diagram for 'with'

[J-P. Rosen]

Le 22/02/2018 à 09:33, Dmitry A. Kazakov a écrit :
> I am keeping on avoiding "limited with", and the only time I lowered my
> guard, it bite me! (:-))
Yes, limited with is a bit of a hack, but remember that the ARG had to
solve the issue of mutual dependency, and 6 other non-working solutions
were considered before this one, not very clean, but that worked!

As a rule of thumb, don't use limited with unless you are unable to
compile due to circular dependencies between package specs. In that
case, carefully consider using one limited with to break the circularity.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Diamond diagram for 'with'

[briot.emmanuel]

> Yes, this is how I came to this, GNAT complained about incomplete types. 
> So it is possible a compiler bug, however I worked it around anyway.

I think there was a compiler bug in that area. We reported a very similar
issue on Jan 13th, and it was fixed in Jan 17th. So not in any public release
yet.

All other advice on not using `limited with` is still good advice ! 

Emmanuel

Re: Diamond diagram for 'with'

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 895 bytes --]

"J-P. Rosen" <rosen@adalog.fr> wrote in message 
news:p6m2e3$4bj$1@dont-email.me...
> Le 22/02/2018 à 09:33, Dmitry A. Kazakov a écrit :
>> I am keeping on avoiding "limited with", and the only time I lowered my
>> guard, it bite me! (:-))
> Yes, limited with is a bit of a hack, but remember that the ARG had to
> solve the issue of mutual dependency, and 6 other non-working solutions
> were considered before this one, not very clean, but that worked!

At least two of those other solutions would have worked, but they were 
considered even more of a hack. (I know the "external incomplete type" 
solution would have worked, because it's basically the same semantically, 
but there were concerns about having (weak) dependencies not exposed in the 
context clause. We fixed that with a context clause declaration, but then it 
really looked like a hack.)

                            Randy.