CVS difference for ai05s/ai05-0074-1.txt

Differences between 1.1 and version 1.2
Log of other versions for file ai05s/ai05-0074-1.txt

--- ai05s/ai05-0074-1.txt	2007/10/25 05:43:52	1.1
+++ ai05s/ai05-0074-1.txt	2007/10/26 01:37:57	1.2
@@ -923,7 +923,7 @@
 ****************************************************************
 
 From: Randy Brukardt
-Date: Wednesday, October 24, 2007  11:326 PM
+Date: Wednesday, October 24, 2007  11:32 PM
 
 ...
 > At any rate, it would be good to explain what exactly is visible after "end
@@ -972,6 +972,273 @@
 
 I'm sure there are more issues to consider. I haven't seen any posting by Steve Baird
 on this yet. ;-) The whole thing sounds like fun. :-(
+
+****************************************************************
+
+From: Tucker Taft
+Date: Thursday, October 25, 2007  7:25 AM
+
+Randy Brukardt wrote:
+> Pascal notes:
+> 
+> ...
+>> At any rate, it would be good to explain what exactly is visible after
+> "end
+>> private" and how you ensure that no private information is leaked out of
+> the
+>> package.
+> 
+> Let's just look at a few cases that would need to be defined:
+> 
+> * What if is there is a use clause in the private part? Does it extend into
+> the following non-private part(s)? [This was from Jean-Pierre.] I think the
+> answer has to be no,  ...
+
+Agreed, clearly no.
+
+> 
+> * How about "additional operations" of a type? That is, in something like:
+> 
+>     package P is
+>        type Q is limited private;
+>     private
+>        type Q is record
+>           A : Integer := 10;
+>        end record;
+>     end private;
+>        Obj : Q;
+>        B : Boolean := (Obj = Obj);
+>     end P;
+> 
+>    Again, probably not. More generally, declarations in a private part
+> should not be visible in a following visible part, so we'd have visibility
+> going out at "end private;" and then returning when we reached the body.
+
+Agreed.
+
+> 
+>     with Func;
+>     package P is
+>        type Q is limited private;
+>     private
+>        type Q is access Integer;
+>        Obj : Q;
+>     end private;
+>        I : Integer := Obj.all;
+>     end P;
+> 
+>    This reduced visibility worries me, as we generally don't lose visibility
+> in a single package: everything is additive (visible part, private part,
+> body). It seems to offer the opportunity for more anomalies.
+
+Perhaps, though I think nested packages with private
+parts are pretty similar.  With nested packages,
+visibility comes and goes.
+
+Child packages are perhaps even closer to this.  When
+you start a child package, although they logically "follow"
+the private part of their ancestor packages,
+they don't "see" the private part.  When you hit
+the private part of the child package, suddenly
+the private declarations of all the ancestors become
+visible.
+
+So from an implementation and anomaly point of view,
+at the "end private;" you might imagine you are starting a
+child package, which cannot take advantage of visibility
+on the parent's private part until it hits its own private
+part or body.
+
+> * Do public children see all of the visible declarations but none of the
+> private ones of their parent? (Seems necessary.)
+
+They don't see the private declarations until they hit their
+own private part or body.  No real surprise here.
+
+> 
+> I'm sure there are more issues to consider. I haven't seen any posting by
+> Steve Baird on this yet. ;-)The whole thing sounds like fun. :-(
+
+Clearly there will be some implementation effects, but I
+don't see many semantic anomalies on the visibility side,
+since I believe a child package experiences much the same
+"coming and going" of visibility.
+
+The anomalies I could imagine would have to do with "completion"
+and overriding, since these kinds of things can't be
+simulated by a child package (though a child subprogram
+can "simulate" overriding in certain non-tagged cases).
+And I agree we will need to work them through if we decide
+to pursue this proposal. I am happy to do so, after
+I have finished my other homework ... ;-).
+
+****************************************************************
+
+From: Robert A. Duff
+Date: Thursday, October 25, 2007  9:15 AM
+
+> Let's just look at a few cases that would need to be defined:
+>...
+
+I'm surprised by Tucker's answer.  My answer is that "obviously", the
+visibility in the second visible part includes everything that came before,
+just as if "end private;" were erased.  (Now Tuck can tell me why that's
+stupid.  ;-))
+
+The purpose of privacy is to hide things from OTHER packages, not from the
+package itself.  This should be legal:
+
+    package P is
+    private
+        type Base_Type is range 1..2**31-1;
+    end private
+        subtype Exported_Type is Base_Type'Base;
+    end P;
+
+to get a type that has at least 32 bits, but matches the hardware bounds.  I
+don't want to pester the client with a useless name -- Base_Type is visible in
+the visible part, but not in clients.
+
+By the way, C++ has a similar feature.  It might help to look at the details,
+which I don't remember.  Of course C++ visibility is quite different from Ada,
+so it might be irrelevant.  And C++ visibility is broken in some ways, so we
+don't necessarily want to mimic it -- but it couldn't hurt to look.
+
+> * Do public children see all of the visible declarations but none of the
+> private ones of their parent? (Seems necessary.)
+
+Yes.
+
+> I'm sure there are more issues to consider. I haven't seen any posting by
+> Steve Baird on this yet. ;-)The whole thing sounds like fun. :-(
+
+Indeed.  I'm not at all sure the whole idea will work.
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Date: Thursday, October 25, 2007  7:34 AM
+
+> Let's just look at a few cases that would need to be defined:
+> 
+And:
+
+I assumed when I read the proposal that there could be several private 
+parts, but I didn't see any mention about that. Is it the intent? That 
+would certainly seem logical from a user point of view:
+
+package Pack is
+   -- visible
+private
+    -- hidden
+end private;
+
+   -- visible again
+
+private
+   -- hidden again
+end Pack;
+
+Have great fun with visibility going in and out!
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Thursday, October 25, 2007  7:56 PM
+
+...
+> >     with Func;
+> >     package P is
+> >        type Q is limited private;
+> >     private
+> >        type Q is access Integer;
+> >        Obj : Q;
+> >     end private;
+> >        I : Integer := Obj.all;
+> >     end P;
+> >
+> >    This reduced visibility worries me, as we generally don't
+> lose visibility
+> > in a single package: everything is additive (visible part, private part,
+> > body). It seems to offer the opportunity for more anomalies.
+>
+> Perhaps, though I think nested packages with private
+> parts are pretty similar.  With nested packages,
+> visibility comes and goes.
+>
+> Child packages are perhaps even closer to this.  When
+> you start a child package, although they logically "follow"
+> the private part of their ancestor packages,
+> they don't "see" the private part.  When you hit
+> the private part of the child package, suddenly
+> the private declarations of all the ancestors become
+> visible.
+
+Not really: within a single unit, all that can happen is the *addition* of
+new things. Once you can see the additional operations, they stay visible
+until the end of the unit. (The situation in outer units may be different,
+but I don't see that as relevant -- we know that visibility can change in
+external units, but it doesn't reduce *directly within* a unit.)
+
+> So from an implementation and anomaly point of view,
+> at the "end private;" you might imagine you are starting a
+> child package, which cannot take advantage of visibility
+> on the parent's private part until it hits its own private
+> part or body.
+
+A child package starts with a "clean" visibility slate, into which the
+parent and other "withs" are loaded. Handling the private part at that point
+is (relatively) easy. A "end private" has a complex visibility state,
+already existing, where things would have to be subtracted piece-meal.
+(Reloading is not an option: you haven't stored it out yet!) This seems
+sustantially more complex. (Of course, I haven't tried implementing this, so
+it might prove easier than I think now.)
+
+> > * Do public children see all of the visible declarations but none of the
+> > private ones of their parent? (Seems necessary.)
+>
+> They don't see the private declarations until they hit their
+> own private part or body.  No real surprise here.
+>
+> > I'm sure there are more issues to consider. I haven't seen any posting
+by
+> > Steve Baird on this yet. ;-)The whole thing sounds like fun. :-(
+>
+> Clearly there will be some implementation effects, but I
+> don't see many semantic anomalies on the visibility side,
+> since I believe a child package experiences much the same
+> "coming and going" of visibility.
+
+No, only "coming". There's no "going": once the private part of a parent is
+visible, it stays that way. It's the "going", for declarations in the same
+unit, which I think doesn't exist currently and has the potential to add
+complications.
+
+Now, I realize that other models of child compilations are possible, but for
+us, each one starts with a clean slate which is built up with whatever is
+needed (a parent is just a hidden "with" of a unit). The only magic is
+making the private part visible when the child "private" is reached, and
+that is a pure addition to visibility.
+
+> The anomalies I could imagine would have to do with "completion"
+> and overriding, since these kinds of things can't be
+> simulated by a child package (though a child subprogram
+> can "simulate" overriding in certain non-tagged cases).
+> And I agree we will need to work them through if we decide
+> to pursue this proposal. I am happy to do so, after
+> I have finished my other homework ... ;-).
+
+Sounds good, especially the part about finishing your other homework. :-)
+
+This issue and the possible solutions are on the agenda for Washington,
+although I'd expect any brainstorming on it to come after we get our other
+work done. (You'll note it is right on the bottom of the list... ;-)
+
+BTW, you are welcome to give the same treatment to the write-up of my
+proposal for this problem that you'll find in AI05-0074-1 (another AI number
+that I fear will live in infamy, like AI-217 [limited with] and AI-359 [the
+4(!) previous versions of this problem]). I hope I can take it as well as I
+dish it out. ;-)
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent