Type vs subtype about visibility of parent's private full definition

Type vs subtype about visibility of parent's private full definition

[Yannick Duchêne (Hibou57)]

Hi all,

I already encountered something similar in the past, and it's back again.  
I can only solve it using a subtype instead of a type‑new where I  
initially want a type‑new, so I'm not happy with using subtype.

The case: a child package don't see the full definition of a type from the  
private part of its parent package when it derives from that type as a  
type‑new.

Below is an example, using a discriminant, which is not required to expose  
the visibility issue, but which is the reason why I'm not happy to not be  
able to derive a type‑new instead of a subtype: I can't force static‑check  
as I expected. If the discriminant was not part of the party, I won't  
bother. That's the reason why the example makes use of a discriminant and  
I see the case as an issue.


Example:


     package Parents is

        pragma Pure;

        type Discriminant_Type is
           range 1 .. 5;

        type Instance_Type
          (Discriminant : Discriminant_Type) is
           private;

     private

        type Instance_Type
          (Discriminant : Discriminant_Type) is
           record
              Value : Integer;
           end record;

     end Parents;

     package Parents.Childs is

        pragma Pure;

        subtype Parent_Type is
           Parents.Instance_Type;

        type Instance_Type is
           new Parent_Type
             (Discriminant => 2);

        function Value
          (Object : Instance_Type)
           return Integer;

     private

        function Value
          (Object : Instance_Type)
           return Integer
           is (Object.Value); -- << Error here

     end Parents.Childs;


I did not check the RM, however I'm blocked if I do this, as GNAT has  
complaints with `is (Object.Value)`, and grumbles:


     no selector "Value" for private type derived from "Instance_Type"


I can just work around it, defining `Parents.Childs.Instance_Type` this  
way:


        subtype Instance_Type is
           Parent_Type
             (Discriminant => 2);


… instead of this way (as was in the above package definition):


        type Instance_Type is
           new Parent_Type
             (Discriminant => 2);


I may be naive, I believe `Parents.Childs` private part should see the  
full definition of `Parents.Instance_Type` in both case, not only when  
deriving a subtype.

What are your opinions about this issue?


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Type vs subtype about visibility of parent's private full definition

[Adam Beneschan]

On Wednesday, May 15, 2013 1:13:00 AM UTC-7, Hibou57 (Yannick Duchêne) wrote:
> Hi all,
> 
> I already encountered something similar in the past, and it's back again.  
> I can only solve it using a subtype instead of a type-new where I  
> initially want a type-new, so I'm not happy with using subtype.
> 
> The case: a child package don't see the full definition of a type from the  
> private part of its parent package when it derives from that type as a  
> type-new.
> 
> Below is an example, using a discriminant, which is not required to expose  
> the visibility issue, but which is the reason why I'm not happy to not be  
> able to derive a type-new instead of a subtype: I can't force static-check  
> as I expected. If the discriminant was not part of the party, I won't  
> bother. That's the reason why the example makes use of a discriminant and  
> I see the case as an issue.

> Example:

>      package Parents is
>         pragma Pure; 
>         type Discriminant_Type is
>            range 1 .. 5;
> 
>         type Instance_Type
>           (Discriminant : Discriminant_Type) is
>            private;
> 
>      private
>         type Instance_Type
>           (Discriminant : Discriminant_Type) is
>            record
>               Value : Integer;
>            end record;
>      end Parents;
> 
>      package Parents.Childs is
>         pragma Pure;
>         subtype Parent_Type is
>            Parents.Instance_Type;
>         type Instance_Type is
>            new Parent_Type
>              (Discriminant => 2);
>         function Value
>           (Object : Instance_Type)
>            return Integer;
>      private
>         function Value
>           (Object : Instance_Type)
>            return Integer
>            is (Object.Value); -- << Error here
>      end Parents.Childs;
> 
> 
> I did not check the RM, however I'm blocked if I do this, as GNAT has  
> complaints with `is (Object.Value)`, and grumbles:
> 
>      no selector "Value" for private type derived from "Instance_Type"

> What are your opinions about this issue?

7.3.1(4) says that the Value component should be visible at that point.  This is a compiler bug.

                             -- Adam

Re: Type vs subtype about visibility of parent's private full definition

[Yannick Duchêne (Hibou57)]

Le Wed, 15 May 2013 16:44:05 +0200, Adam Beneschan <adam@irvine.com> a  
écrit:

> 7.3.1(4) says that the Value component should be visible at that point.   
> This is a compiler bug.
>
>                              -- Adam

Indeed this looks to say it. I would have not thought to look in “7.3.1  
Private Operations” as this was not about operation, and “8.3 Visibility”  
does not refers to it neither. Sometime it's not that easy to seek in the  
RM :p (even using the Index).

So I will go with subtype anyway (have no choice), and will mark this with  
a comment like “-- GNAT bug” to remind me (and may be others, who know)  
it's not an Ada issue.

Thanks Adam :)

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Type vs subtype about visibility of parent's private full definition

[Marc C]

On Wednesday, May 15, 2013 3:45:24 PM UTC-5, Hibou57 (Yannick Duchêne) wrote:

> So I will go with subtype anyway (have no choice), and will mark this with  
> a comment like “-- GNAT bug” to remind me (and may be others, who know)  
> it's not an Ada issue.

And also send a writeup on this to report@adacore.com so they're aware of it. Include your test program, the LRM references, and maybe a link to this discussion thread.

Since you're not a supported user it's unlikely they'll jump to fix it, but it likely will be fixed at some point.

Marc A. Criley

Re: Type vs subtype about visibility of parent's private full definition

[Simon Wright]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

> I already encountered something similar in the past, and it's back
> again. I can only solve it using a subtype instead of a type‑new where
> I initially want a type‑new, so I'm not happy with using subtype.
>
> The case: a child package don't see the full definition of a type from
> the private part of its parent package when it derives from that type
> as a type‑new.
>
> Below is an example, using a discriminant, which is not required to
> expose the visibility issue, but which is the reason why I'm not happy
> to not be able to derive a type‑new instead of a subtype: I can't
> force static‑check as I expected. If the discriminant was not part of
> the party, I won't bother. That's the reason why the example makes use
> of a discriminant and I see the case as an issue.
>
>
> Example:
>
>
>     package Parents is
>
>        pragma Pure;
>
>        type Discriminant_Type is
>           range 1 .. 5;
>
>        type Instance_Type
>          (Discriminant : Discriminant_Type) is
>           private;
>
>     private
>
>        type Instance_Type
>          (Discriminant : Discriminant_Type) is
>           record
>              Value : Integer;
>           end record;
>
>     end Parents;
>
>     package Parents.Childs is
>
>        pragma Pure;
>
>        subtype Parent_Type is
>           Parents.Instance_Type;
>
>        type Instance_Type is
>           new Parent_Type
>             (Discriminant => 2);

There may or may not be a compiler bug triggered by this form, but I
don't understand why you say "I can only solve it using a subtype
instead of a type‑new where I initially want a type‑new, so I'm not
happy with using subtype" because if I write instead of Parent_Type and
Instance_Type above

   type Instance_Type is
     new Parents.Instance_Type
     (Discriminant => 2);

or

   subtype Instance_Type is
     Parents.Instance_Type
     (Discriminant => 2);

it compiles OK.

>        function Value
>          (Object : Instance_Type)
>           return Integer;
>
>     private
>
>        function Value
>          (Object : Instance_Type)
>           return Integer
>           is (Object.Value); -- << Error here
>
>     end Parents.Childs;
>
>
> I did not check the RM, however I'm blocked if I do this, as GNAT has
> complaints with `is (Object.Value)`, and grumbles:
>
>
>     no selector "Value" for private type derived from "Instance_Type"
>
>
> I can just work around it, defining `Parents.Childs.Instance_Type`
> this way:
>
>
>        subtype Instance_Type is
>           Parent_Type
>             (Discriminant => 2);
>
>
> … instead of this way (as was in the above package definition):
>
>
>        type Instance_Type is
>           new Parent_Type
>             (Discriminant => 2);
>
>
> I may be naive, I believe `Parents.Childs` private part should see the
> full definition of `Parents.Instance_Type` in both case, not only when
> deriving a subtype.
>
> What are your opinions about this issue?

Re: Type vs subtype about visibility of parent's private full definition

[Yannick Duchêne (Hibou57)]

Le Thu, 16 May 2013 17:29:13 +0200, Simon Wright <simon@pushface.org> a  
écrit:
> if I write instead of Parent_Type and
> Instance_Type above
>
>    type Instance_Type is
>      new Parents.Instance_Type
>      (Discriminant => 2);
>
> or
>
>    subtype Instance_Type is
>      Parents.Instance_Type
>      (Discriminant => 2);
>
> it compiles OK.

The first does not compile for me with GNAT from GCC 4.8, it fails with  
the message given in the original message, which is “no selector "Value"  
for private type derived from "Instance_Type"”.

What GNAT flavour did you tried it with? GNAT Pro or GPL or FSF?

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Type vs subtype about visibility of parent's private full definition

[Yannick Duchêne (Hibou57)]

Le Thu, 16 May 2013 22:25:12 +0200, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:

> Le Thu, 16 May 2013 17:29:13 +0200, Simon Wright <simon@pushface.org> a  
> écrit:
>> if I write instead of Parent_Type and
>> Instance_Type above
>>
>>    type Instance_Type is
>>      new Parents.Instance_Type
>>      (Discriminant => 2);
>>
>> or
>>
>>    subtype Instance_Type is
>>      Parents.Instance_Type
>>      (Discriminant => 2);
>>
>> it compiles OK.

Sorry for the previous message, I missed you used `Parents.Instance_Type`  
and will try this variant. Anyway, that still seems to be a bug, as the  
behaviour should be the same in both cases, using either  
`Parents.Instance_Type` or a `Parent_Type` subtype.

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Type vs subtype about visibility of parent's private full definition

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:309db8ab-239d-4b06-9450-3a0b098f3953@googlegroups.com...
...
>> What are your opinions about this issue?
>
>7.3.1(4) says that the Value component should be visible at that point. 
>This is a compiler bug.

Humm, I'm not sure that GNAT is wrong here. There is a long tradition of 
tests where you might thing components would be available but are not. I'm 
not certain if this is one of those cases or not, but I direct your 
attention to 7.3.1(5.1/3) [which exists to clarify the language because of a 
bug that some Beneschan guy reported with record aggregates].

The reason I said that I'm "not sure" is that this is a very messy area, and 
what is supposed to happen depends very much upon the exact example. (I 
would blow this all away in my language redesign -- it has wasted far too 
much time for its value.)

                                              Randy.

Re: Type vs subtype about visibility of parent's private full definition

[Adam Beneschan]

On Thursday, May 16, 2013 5:01:02 PM UTC-7, Randy Brukardt wrote:

> ...
> 
> >> What are your opinions about this issue?
> 
> >7.3.1(4) says that the Value component should be visible at that point. 
> >This is a compiler bug.
> 
> Humm, I'm not sure that GNAT is wrong here. There is a long tradition of 
> tests where you might thing components would be available but are not.

My recollection is that those cases involve multiple derivations where type T1 is declared in a Parent package, type extension T2 is derived from T1 in a package that is not a child of Parent, and T3 is derived from T2 in a child of Parent; although normally the private part and body of Parent.Child would be able to see the private part of Parent, there were some language issues because of the type T2 in the middle, which couldn't inherit all the operations from T1 because they weren't visible at any place.  Yannick's example doesn't involve that, so this case shouldn't be as messy.

                              -- Adam