* Visibility Rules For Children @ 1998-10-26 0:00 Matthew Heaney 1998-10-26 0:00 ` Martin Dowie ` (3 more replies) 0 siblings, 4 replies; 8+ messages in thread From: Matthew Heaney @ 1998-10-26 0:00 UTC (permalink / raw) 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; ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Visibility Rules For Children 1998-10-26 0:00 Visibility Rules For Children Matthew Heaney @ 1998-10-26 0:00 ` Martin Dowie 1998-10-27 0:00 ` Robert A Duff 1998-10-27 0:00 ` Robert A Duff ` (2 subsequent siblings) 3 siblings, 1 reply; 8+ messages in thread From: Martin Dowie @ 1998-10-26 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Visibility Rules For Children 1998-10-26 0:00 ` Martin Dowie @ 1998-10-27 0:00 ` Robert A Duff 1998-10-27 0:00 ` Martin Dowie 0 siblings, 1 reply; 8+ messages in thread From: Robert A Duff @ 1998-10-27 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Visibility Rules For Children 1998-10-27 0:00 ` Robert A Duff @ 1998-10-27 0:00 ` Martin Dowie 0 siblings, 0 replies; 8+ messages in thread From: Martin Dowie @ 1998-10-27 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Visibility Rules For Children 1998-10-26 0:00 Visibility Rules For Children Matthew Heaney 1998-10-26 0:00 ` Martin Dowie @ 1998-10-27 0:00 ` Robert A Duff 1998-10-28 0:00 ` Stephen Leake 1998-11-02 0:00 ` Tucker Taft 3 siblings, 0 replies; 8+ messages in thread From: Robert A Duff @ 1998-10-27 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Visibility Rules For Children 1998-10-26 0:00 Visibility Rules For Children Matthew Heaney 1998-10-26 0:00 ` Martin Dowie 1998-10-27 0:00 ` Robert A Duff @ 1998-10-28 0:00 ` Stephen Leake 1998-10-29 0:00 ` Matthew Heaney 1998-11-02 0:00 ` Tucker Taft 3 siblings, 1 reply; 8+ messages in thread From: Stephen Leake @ 1998-10-28 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Visibility Rules For Children 1998-10-28 0:00 ` Stephen Leake @ 1998-10-29 0:00 ` Matthew Heaney 0 siblings, 0 replies; 8+ messages in thread From: Matthew Heaney @ 1998-10-29 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Visibility Rules For Children 1998-10-26 0:00 Visibility Rules For Children Matthew Heaney ` (2 preceding siblings ...) 1998-10-28 0:00 ` Stephen Leake @ 1998-11-02 0:00 ` Tucker Taft 3 siblings, 0 replies; 8+ messages in thread From: Tucker Taft @ 1998-11-02 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~1998-11-02 0:00 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1998-10-26 0:00 Visibility Rules For Children Matthew Heaney 1998-10-26 0:00 ` Martin Dowie 1998-10-27 0:00 ` Robert A Duff 1998-10-27 0:00 ` Martin Dowie 1998-10-27 0:00 ` Robert A Duff 1998-10-28 0:00 ` Stephen Leake 1998-10-29 0:00 ` Matthew Heaney 1998-11-02 0:00 ` Tucker Taft
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox