Visibility Rules For Children

Visibility Rules For Children

[Matthew Heaney]

What are the visibility rules for children?

In the code fragment below, I have a procedure, GC, that is a child of
parent package GP.  The child is a generic that imports generic formal
type NT, derived from type T, declared in the parent package GP.

The parent type T (and its derived type NT, of course) has an Integer
component I.  All the child operation does is set the value of that
component.

Yet, the compiler is telling me that the child can't see the component I
of NT:

(start of message)
q.ads:8:04: instantiation error at gp-gc.adb:3
q.ads:8:04: undefined selector for type "NT" defined at line 6
gnatmake: "/home/matt/acl/impls/q.ads" compilation error

Compilation exited abnormally with code 2 at Mon Oct 26 03:53:30
(end of message)

This is unexpected, since I thought that children could see the
private components of types declared in the parent.

Does this have anything to do with the fact that the child is looking at
a type derived from the parent type, and not at the parent type
directly?

Is a view conversion to the parent type always required here?

This...
procedure GP.GC (O : in out NT) is
begin
   T (O).I := 1;
end;

...instead of
procedure GP.GC (O : in out NT) is
begin
   O.I := 1;
end;


Thanks,
Matt


generic
   type FT is private;
package GP is
   type T is tagged limited private;
private
   type T is
      tagged limited  record
        I : Integer;
      end record;
end GP;


generic
   type NT is new T with private;
procedure GP.GC (O : in out NT);


procedure GP.GC (O : in out NT) is
begin
   O.I := 1;
end;


with GP;
package P is new GP (Integer);


with P;
with GP.GC;
package Q is
   type NT is new P.T with null record;
   procedure C is new P.GC (NT);
end;


with Q;
procedure Test_Q is
begin
   null;
end;

Re: Visibility Rules For Children

[Martin Dowie]

In article <m34sss6juk.fsf@mheaney.ni.net>, Matthew Heaney
<matthew_heaney@acm.org> writes
>What are the visibility rules for children?
>
[snip]
LRM:3.9.2(13), a primitive subprogram of a tagged type may not be
declared after the type is frozen
-- 
Martin Dowie

Re: Visibility Rules For Children

[Martin Dowie]

oops - as i mentioned to matthew, i'm having real trouble with my newsgroup
s/w - the following was missed off my reply -

"i can't even get your sample code to compile using ObjectAda 7.1 and gives
the following error -"

however are user defined subprograms of derived types primitive subprograms?
in this case 'Q.C'.

Robert A Duff wrote in message ...
>Martin Dowie <martin@dowie-cs.demon.co.uk> writes:
>
>> LRM:3.9.2(13), a primitive subprogram of a tagged type may not be
>> declared after the type is frozen
>
>But there are no primitive subprograms in Mr. Heaney's example...
>
>- Bob
>--
>Change robert to bob to get my real email address.  Sorry.

Re: Visibility Rules For Children

[Robert A Duff]

Matthew Heaney <matthew_heaney@acm.org> writes:

> What are the visibility rules for children?

They're pretty subtle.  Read 3.4, 7.3.1, and 12.something.

Your example looks legal to me.  There is a place immediately within the
immediate scope of the derived type, where I is visible; therefore, the
inherited I should also become visible.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Visibility Rules For Children

[Robert A Duff]

Martin Dowie <martin@dowie-cs.demon.co.uk> writes:

> LRM:3.9.2(13), a primitive subprogram of a tagged type may not be
> declared after the type is frozen

But there are no primitive subprograms in Mr. Heaney's example...

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Visibility Rules For Children

[Stephen Leake]

Matthew Heaney <matthew_heaney@acm.org> writes:

> What are the visibility rules for children?

<snip>

After rearranging the test code (see below) to avoid declaring a new
primitive subprogram C, ObjectAda 7.1.2 gives the helpful error
message:

matt.adb: Internal: line 38 col 14 improve_context found null in
ili_slot 1 of 12407E0, Returning unimproved context
       (In instance of generic GC in matt.adb)

So I can't tell if Tucker Taft's favorite front end thinks this is
legal or not :).

You do have a penchant for finding compiler bugs! 

-- Stephe

generic
   type FT is private;
package GP is
   type T is tagged limited private;
private
   type T is
      tagged limited  record
        I : Integer;
      end record;
end GP;


generic
   type NT is new T with private;
procedure GP.GC (O : in out NT);


procedure GP.GC (O : in out NT) is
begin
   O.I := 1;
end;


with GP;
package P is new GP (Integer);


with P;
package Q is
   type NT is new P.T with null record;
end;


with P;
with Q;
with GP.GC;
procedure Test_Q is
   procedure C is new P.GC (Q.NT);
begin

Re: Visibility Rules For Children

[Matthew Heaney]

Stephen Leake <Stephen.Leake@gsfc.nasa.gov> writes:

> After rearranging the test code (see below) to avoid declaring a new
> primitive subprogram C, ObjectAda 7.1.2 gives the helpful error
> message:
> 
> matt.adb: Internal: line 38 col 14 improve_context found null in
> ili_slot 1 of 12407E0, Returning unimproved context
>        (In instance of generic GC in matt.adb)

Oh, so that explains it!


> So I can't tell if Tucker Taft's favorite front end thinks this is
> legal or not :).
> 
> You do have a penchant for finding compiler bugs! 

So it seems.  I've been working on the Ada Components Library (ACL), and
have been excercising all language features together.  I found a bunch
of (what I believe to be) bugs in gnat v3.10p, but didn't bother
reporting them, as v3.11 is only a couple of weeks away.

Re: Visibility Rules For Children

[Tucker Taft]

Matthew Heaney (matthew_heaney@acm.org) wrote:

: What are the visibility rules for children?

They are intended to be very similar to nested units.
In general, when you declare a public child, it has the same visibility
as a unit nested in the visible part of the parent's spec, whereas
if you declare a private child, it has the same visibility as a unit
nested in the private part of the parent's spec.
In either case, the body of the child logically occurs inside the parent,
"between" the private part of its spec and the beginning of its body.

: In the code fragment below, I have a procedure, GC, that is a child of
: parent package GP.  The child is a generic that imports generic formal
: type NT, derived from type T, declared in the parent package GP.

: The parent type T (and its derived type NT, of course) has an Integer
: component I.  All the child operation does is set the value of that
: component.

: Yet, the compiler is telling me that the child can't see the component I
: of NT:

: (start of message)
: q.ads:8:04: instantiation error at gp-gc.adb:3
: q.ads:8:04: undefined selector for type "NT" defined at line 6
: gnatmake: "/home/matt/acl/impls/q.ads" compilation error

: Compilation exited abnormally with code 2 at Mon Oct 26 03:53:30
: (end of message)

: This is unexpected, since I thought that children could see the
: private components of types declared in the parent.

: Does this have anything to do with the fact that the child is looking at
: a type derived from the parent type, and not at the parent type
: directly?

Yes, and with the fact that the type NT is defined in a place
where the full type of T is not visible (since the visible part of the 
spec of a public child does not "see" the private declarations of its parent).
RM95 paragraph 7.3.1(4) is perhaps relevant here, though it is a bit unclear
whether it applies to (formal) private extensions.  

7.3.1(4) indicates that components of the parent become components of the 
derived type at the first point in the immediate scope of the derived type
where the parent's components are visible.  This would presumably
be in the body of the child generic subprogram, since there is no
private part of a (generic) subprogram.  However, 7.3.1(4) explicitly
talks about types defined by a derived_type_definition, which
(formal) private extensions are not.  Furthermore, inherited subprograms
work differently for private extensions, so one might think that
components should also work differently.  However 7.3(16) and 12.5.1(20)
say that (formal) private extensions inherit components from the
ancestor type "as for a derived type defined by a derived_type_definition."

All in all, there seems a bit of a muddle about component visibility
of (formal) private extensions after their ancestor types become "more"
visible.  Probably an "AI" (Ada Interpretation) would help here...

: Is a view conversion to the parent type always required here?

It will certainly help!  Based on the above long discourse, it
is a bit unclear whether it is required.  The whole issue of when
private characteristics of a parent type become visible for a derived
type is tricky, but a conversion to the parent type is always sure to work.

: This...
: procedure GP.GC (O : in out NT) is
: begin
:    T (O).I := 1;
: end;

: ...instead of
: procedure GP.GC (O : in out NT) is
: begin
:    O.I := 1;
: end;


: Thanks,
: Matt

For what it is worth, after fixing the bug in "my favorite front end"
which was causing it to die on this test case, it accepted your
original program without complaint (i.e. it decided the parent's
component "I" was visible in the body of GC).  However, in a similar
program where the generic subprogram was physically nested in the parent 
generic, it concluded that this component was not visible in the generic 
subprogram's body.

The main difference being that the child's formal private extension
is declared *after* the full type of the parent has been declared,
though in a place where the full type is not yet visible, whereas
in the nested case, it is declared *before* the full type has been
declared.  I'm not convinced this distinction is justified
by the (admittedly less-than-crystal-clear) RM wording...

-Tucker Taft  stt@inmet.com
Intermetrics, Inc.

----------------------

: generic
:    type FT is private;
: package GP is
:    type T is tagged limited private;
: private
:    type T is
:       tagged limited  record
:         I : Integer;
:       end record;
: end GP;


: generic
:    type NT is new T with private;
: procedure GP.GC (O : in out NT);


: procedure GP.GC (O : in out NT) is
: begin
:    O.I := 1;
: end;


: with GP;
: package P is new GP (Integer);


: with P;
: with GP.GC;
: package Q is
:    type NT is new P.T with null record;
:    procedure C is new P.GC (NT);
: end;


: with Q;
: procedure Test_Q is
: begin
:    null;
: end;



--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA
An AverStar Company