* Type vs subtype about visibility of parent's private full definition
@ 2013-05-15 8:13 Yannick Duchêne (Hibou57)
2013-05-15 14:44 ` Adam Beneschan
2013-05-16 15:29 ` Simon Wright
0 siblings, 2 replies; 9+ messages in thread
From: Yannick Duchêne (Hibou57) @ 2013-05-15 8:13 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Type vs subtype about visibility of parent's private full definition
2013-05-15 8:13 Type vs subtype about visibility of parent's private full definition Yannick Duchêne (Hibou57)
@ 2013-05-15 14:44 ` Adam Beneschan
2013-05-15 20:45 ` Yannick Duchêne (Hibou57)
2013-05-17 0:01 ` Randy Brukardt
2013-05-16 15:29 ` Simon Wright
1 sibling, 2 replies; 9+ messages in thread
From: Adam Beneschan @ 2013-05-15 14:44 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Type vs subtype about visibility of parent's private full definition
2013-05-15 14:44 ` Adam Beneschan
@ 2013-05-15 20:45 ` Yannick Duchêne (Hibou57)
2013-05-16 13:54 ` Marc C
2013-05-17 0:01 ` Randy Brukardt
1 sibling, 1 reply; 9+ messages in thread
From: Yannick Duchêne (Hibou57) @ 2013-05-15 20:45 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Type vs subtype about visibility of parent's private full definition
2013-05-15 20:45 ` Yannick Duchêne (Hibou57)
@ 2013-05-16 13:54 ` Marc C
0 siblings, 0 replies; 9+ messages in thread
From: Marc C @ 2013-05-16 13:54 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Type vs subtype about visibility of parent's private full definition
2013-05-15 8:13 Type vs subtype about visibility of parent's private full definition Yannick Duchêne (Hibou57)
2013-05-15 14:44 ` Adam Beneschan
@ 2013-05-16 15:29 ` Simon Wright
2013-05-16 20:25 ` Yannick Duchêne (Hibou57)
1 sibling, 1 reply; 9+ messages in thread
From: Simon Wright @ 2013-05-16 15:29 UTC (permalink / raw)
"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?
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Type vs subtype about visibility of parent's private full definition
2013-05-16 15:29 ` Simon Wright
@ 2013-05-16 20:25 ` Yannick Duchêne (Hibou57)
2013-05-16 20:28 ` Yannick Duchêne (Hibou57)
0 siblings, 1 reply; 9+ messages in thread
From: Yannick Duchêne (Hibou57) @ 2013-05-16 20:25 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Type vs subtype about visibility of parent's private full definition
2013-05-16 20:25 ` Yannick Duchêne (Hibou57)
@ 2013-05-16 20:28 ` Yannick Duchêne (Hibou57)
0 siblings, 0 replies; 9+ messages in thread
From: Yannick Duchêne (Hibou57) @ 2013-05-16 20:28 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Type vs subtype about visibility of parent's private full definition
2013-05-15 14:44 ` Adam Beneschan
2013-05-15 20:45 ` Yannick Duchêne (Hibou57)
@ 2013-05-17 0:01 ` Randy Brukardt
2013-05-17 15:48 ` Adam Beneschan
1 sibling, 1 reply; 9+ messages in thread
From: Randy Brukardt @ 2013-05-17 0:01 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Type vs subtype about visibility of parent's private full definition
2013-05-17 0:01 ` Randy Brukardt
@ 2013-05-17 15:48 ` Adam Beneschan
0 siblings, 0 replies; 9+ messages in thread
From: Adam Beneschan @ 2013-05-17 15:48 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2013-05-17 15:48 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-05-15 8:13 Type vs subtype about visibility of parent's private full definition Yannick Duchêne (Hibou57)
2013-05-15 14:44 ` Adam Beneschan
2013-05-15 20:45 ` Yannick Duchêne (Hibou57)
2013-05-16 13:54 ` Marc C
2013-05-17 0:01 ` Randy Brukardt
2013-05-17 15:48 ` Adam Beneschan
2013-05-16 15:29 ` Simon Wright
2013-05-16 20:25 ` Yannick Duchêne (Hibou57)
2013-05-16 20:28 ` Yannick Duchêne (Hibou57)
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox