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

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

--- ai05s/ai05-0074-2.txt	2008/08/01 04:26:14	1.2
+++ ai05s/ai05-0074-2.txt	2008/08/08 05:21:31	1.3
@@ -3800,3 +3800,1166 @@
 
 ****************************************************************
 
+From: Tucker Taft
+Date: Friday, August 1, 2008 10:52 AM
+
+> Later in the discussion:
+> 
+>> Allowing "end private;" has relatively straightforward semantics, 
+>> with no new freezing rules or new kinds of instantiations. Other than 
+>> the syntax change, the main significant change is the proposed 8.2 
+>> rule that the immediate scope of a declaration in the private part 
+>> does *not* include the list of visible declarations, if any, that 
+>> follow "end private;". This makes them very similar to the 
+>> declarations in the visible part of a child unit.
+> 
+> Humm, if we don't have any new freezing rules, then we have privacy 
+> leakage of freezing. Back in the day, Pascal would have screamed 
+> bloody murder because of the damage to incremental compilation.
+
+I had thought about freezing all entities other than incomplete types
+at the point of the "end private," but then I bumped into some situations
+where that was undesirably restrictive.  For example
+
+     package Abc is
+        type X is private;
+        procedure Foo(X : Integer);
+       private
+          type X is record ... end record;
+       end private;
+        package P is new Gen(X);
+        procedure Foo(X : Integer) renames P.Fum;
+     end Abc;
+
+If we force "Foo" to be frozen at the "end private" then the renaming would
+not be permitted, and could not be moved into the body if the calling
+convention of P.Fum was not "Ada."
+
+The "freezing" leakage doesn't seem so bad, because it is very local.
+No code outside the package could be affected by anything it learns one way
+or the other, so if the implementor decides to change the private part in
+a subsequent release of the package, if they can manage to keep the visible
+part compatible, the clients would be unaffected.  If they can't keep the
+visible part compatible, then that is the implementor's problem.  In any
+case it doesn't affect clients.
+
+> 
+> For instance:
+> 
+>    package Leaker is
+>        type Int is range 0 .. 100;
+>    private
+>        Obj : Int; -- Freezes Int.
+>    end private; -- I really hate this semicolon; it feels to me as 
+> natural as "end record" (that is, not at all).
+>        for Int'Size use 8; -- Illegal, Int is frozen.
+>    end Leaker;
+> 
+> Of course, if Obj is removed, then the rep. clause is allowed.
+> 
+> I can't get too upset about this particular problem (which is why I 
+> labeled this "quibbles", not "issues"). It could be fixed by simply 
+> disallowing representation items in secondary visible part for 
+> entities declared in the primary visible part. That of course would be 
+> compatible (there being no secondary visible part in older Ada). I 
+> think that allowing representation clauses far away from their 
+> declarations is a major mistake in Ada, and I'd be happy to rein that "feature" in somewhat.
+> 
+> But I do wonder if there are other effects of this "freezing leakage" 
+> that would be more serious. I can't think of any off-hand. But perhaps 
+> we need to consider freezing everything at the end of the private part 
+> (just as we do today); then there can be no private freezing leakage.
+
+
+Again, I don't think it is a significant problem because it doesn't interfere
+with information hiding.  The client can't become dependent on whether the
+freezing happens inside or outside, since it definitely happens by the time
+the compilation unit containing the package is completed.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Friday, August 1, 2008  3:03 PM
+
+> The "freezing" leakage doesn't seem so bad, because it is very local.  
+> No code outside the package could be affected by anything it learns 
+> one way or the other, so if the implementor decides to change the 
+> private part in a subsequent release of the package, if they can 
+> manage to keep the visible part compatible, the clients would be 
+> unaffected.
+>  If they can't keep the visible part compatible, then that is the 
+> implementor's problem.  In any case it doesn't affect clients.
+
+It's true that freezing itself can't affect clients, but surely the things
+that you can do with it could. For instance, consider a modification of your
+example:
+
+      package Abc is
+         type X is tagged private;
+      private
+         type X is tagged record ... end record;
+      end private;
+         package P is new Gen(X);
+         for X'Write use P.Fum;
+      end Abc;
+
+The fact that the representation clause is visible affects availability (and
+thus legality) of later extensions.
+
+Your comment about maintainer beware is true, I suppose, but I still am nervous
+about this leakage. It's too bad that we don't have anyone who could tell us
+if this sort of leakage would be a problem for the IBM compiler's incremental
+compilation.
+
+In any case, this needs to be in the discussion somewhere, because we need to
+know that the potential problems were considered.
+
+BTW, the "end private;" (especially the semicolon) in the above makes me ill.
+The semicolon should only occur at the end of a construct, and a private part
+is not a construct (it is just a part). I'd rather we used syntax like:
+
+      package Abc is
+         type X is tagged private;
+      private
+         type X is tagged record ... end record;
+      visible
+         package P is new Gen(X);
+         for X'Write use P.Fum;
+      end Abc;
+
+which looks much more consistent.
+
+Another off-the-wall comment: do we need to add this extra part in other places
+where we have private parts (tasks and protected)? It seems inconsistent if
+we don't, even though it doesn't seem very useful in those cases.
+
+****************************************************************
+
+From: Tucker Taft
+Date: Friday, August 1, 2008  7:15 PM
+
+> The fact that the representation clause is visible affects 
+> availability (and thus legality) of later extensions.
+
+That doesn't look legal to me, since X is frozen by the time you get 
+to the "for X'Write use ...". But in any case your point is valid,
+but again, it seems to be all about what appears in the post-private
+visible part, not about what may or may not be in the private part.
+If either visible part changes, then clearly the clients are affected.
+It is true that changes in the private part might affect the legality
+of items in the visible part, but that is already true.  Clearly you
+should spec-out your visible part first, and then construct and place
+the private part to support the visible declarations.
+
+> Your comment about maintainer beware is true, I suppose, but I still 
+> am nervous about this leakage. It's too bad that we don't have anyone 
+> who could tell us if this sort of leakage would be a problem for the 
+> IBM compiler's incremental compilation.
+
+I presume Pascal and Steve have some memory of these issues...
+
+> In any case, this needs to be in the discussion somewhere, because we 
+> need to know that the potential problems were considered.
+
+Agreed.
+
+> BTW, the "end private;" (especially the semicolon) in the above makes 
+> me ill. The semicolon should only occur at the end of a construct, and 
+> a private part is not a construct (it is just a part). I'd rather we 
+> used syntax like:
+> 
+>       package Abc is
+>          type X is tagged private;
+>       private
+>          type X is tagged record ... end record;
+>       visible
+>          package P is new Gen(X);
+>          for X'Write use P.Fum;
+>       end Abc;
+> 
+> which looks much more consistent.
+
+Perhaps.  However, I had originally asked about leaving off the ";" on
+"end private;" and that made John ill.
+You may remember I also proposed "not private"... ;-).
+
+Note also that semicolons do appear in the middle of constructs, in particular,
+for formal parameters, though admittedly those are as separators rather
+than terminators (which is arguably not a feature!).
+
+> Another off-the-wall comment: do we need to add this extra part in 
+> other places where we have private parts (tasks and protected)? It 
+> seems inconsistent if we don't, even though it doesn't seem very 
+> useful in those cases.
+
+I considered that, and in fact the wording I added in various places doesn't
+preclude them, but I couldn't find an argument for making the syntax change.
+Perhaps someone else will, or will feel the uniformity argument is sufficiently
+strong to justify them.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Friday, August 1, 2008  7:32 PM
+
+> Perhaps.  However, I had originally asked about leaving off the ";" on 
+> "end private;" and that made John ill.
+> You may remember I also proposed "not private"... ;-).
+
+Yes, I recall John's issue. And I think he is right, in that a semicolon
+should go with an "end", but for the wrong reason: "end" doesn't belong
+in the middle of anything.
+
+"not private" is fairly ambiguous. I think a new keyword is justified
+(especially as there will be more assuming some of the other proposals
+are adopted).
+
+Perhaps that keyword should be "public" rather than "visible".
+
+      package Abc is
+         type X is tagged private;
+      private
+         type X is tagged record ... end record;
+      public
+         package P is new Gen(X);
+         for X'Write use P.Fum;
+      end Abc;
+
+> Note also that semicolons do appear in the middle of constructs, in 
+> particular, for formal parameters, though admittedly those are as 
+> separators rather than terminators (which is arguably not a feature!).
+
+Yes, and I sometimes write those as commas and find out when the compiler
+complains. Two wrongs don't make a right. Anyway, this isn't very important,
+but I wanted to put my position on the record.
+
+> > Another off-the-wall comment: do we need to add this extra part in 
+> > other places where we have private parts (tasks and protected)? It 
+> > seems inconsistent if we don't, even though it doesn't seem very 
+> > useful in those cases.
+> 
+> I considered that, and in fact the wording I added in various places 
+> doesn't preclude them, but I couldn't find an argument for making the 
+> syntax change.  Perhaps someone else will, or will feel the uniformity 
+> argument is sufficiently strong to justify them.
+
+The only argument for the change is consistency (I don't think there is any
+semantic need). OTOH, there isn't any semantic need for private parts for tasks,
+and yet we still have them. So I lean toward adding these parts (if for no
+other reason than not having to remember where they are allowed).
+Another thing that is not very important.
+
+****************************************************************
+
+From: Robert A. Duff
+Date: Friday, August 1, 2008  9:16 PM
+
+> The only argument for the change is consistency (I don't think there 
+> is any semantic need). OTOH, there isn't any semantic need for private 
+> parts for tasks, and yet we still have them.
+
+They are needed if you want to have an entry that the task requeues upon, and keep
+that entry private to the task.
+
+****************************************************************
+
+From: Dan Eilers
+Date: Friday, August 1, 2008  4:00 PM
+
+Would the following be legal?
+
+      package Abc is
+       private
+          type X is record ... end record;
+       end private;
+         type X is private;
+      end Abc;
+
+That is, can a private type declaration appear in the trailing visible part?
+
+If someone wrote:
+
+      package Abc2 is
+       private
+          type hidden_X is record ... end record;
+       end private;
+         type X is new hidden_X;
+      end Abc2;
+
+would X be essentially a private type?
+
+If we allow trailing visible parts, could a user put all the visible declarations there,
+in order to keep them together?
+
+****************************************************************
+
+From: Tucker Taft
+Date: Saturday, August 2, 2008  3:56 AM
+
+> Would the following be legal?
+> 
+>       package Abc is
+>        private
+>           type X is record ... end record;
+>        end private;
+>          type X is private;
+>       end Abc;
+> 
+> That is, can a private type declaration appear in the trailing visible 
+> part?
+
+No.  In the proposal as written, private types and deferred constants
+are only permitted in the pre-private visible part.
+
+> 
+> If someone wrote:
+> 
+>       package Abc2 is
+>        private
+>           type hidden_X is record ... end record;
+>        end private;
+>          type X is new hidden_X;
+>       end Abc2;
+> 
+> would X be essentially a private type?
+
+The post-private visible part has no visibility on the declarations of the
+private part (you might want to reread the AI ;-).
+ 
+> If we allow trailing visible parts, could a user put all the visible 
+> declarations there, in order to keep them together?
+
+Not if any of them are private types or deferred constants.
+
+****************************************************************
+
+From: John Barnes
+Date: Monday, August 4, 2008  1:40 AM
+
+>> Perhaps.  However, I had originally asked about leaving off the ";" 
+>> on "end private;" and that made John ill.
+
+Yes it did.
+
+
+>> You may remember I also proposed "not private"... ;-).
+>
+> Yes, I recall John's issue. And I think he is right, in that a 
+> semicolon should go with an "end", but for the wrong reason: "end" 
+> doesn't belong in the middle of anything.
+>
+> "not private" is fairly ambiguous. I think a new keyword is justified 
+> (especially as there will be more assuming some of the other proposals 
+> are adopted).
+
+A new keyword does seem a bit of a luxury.
+
+> Perhaps that keyword should be "public" rather than "visible".
+
+But if we are going to have one then public is good. Can we think of
+ther uses for public?
+
+****************************************************************
+
+From: Dan Eilers
+Date: Monday, August 4, 2008  5:34 PM
+
+> > Would the following be legal?
+> >
+> >       package Abc is
+> >        private
+> >           type X is record ... end record;
+> >        end private;
+> >          type X is private;
+> >       end Abc;
+> >
+> > That is, can a private type declaration appear in the trailing 
+> > visible part?
+>
+> No.  In the proposal as written, private types and deferred constants 
+> are only permitted in the pre-private visible part.
+
+OK, but why?
+
+It seems to me to be an unnecessary complication to propose that the
+rules for what's allowed in the trailing visible part be different
+(no private types or deferred constants) from the rules for the leading
+visible part.
+
+There wouldn't seem to me to be any problem with privacy leakage or
+elaboration ordering, etc.  I understand that the trailing visible part
+is proposed to have no visibility on the private part, but I don't think
+that presents an obstacle, since the leading visible part doesn't have
+such visibility either, and it can declare private types and deferred
+constants with confidence that their full definition will appear in
+the private part.
+
+The name "deferred" constants would be somewhat odd, for constants that
+are made visible in a trailing visible part, but that's more of a
+naming issue.  Maybe we should call them "hidden" constants instead of
+"deferred".
+
+What I am getting at is that maybe we could simplify the proposed
+"sandwich" structure, and give the user the option of either a leading
+visible part or a trailing visible part, but not both in the same package.
+This would have the advantage that the trailing visible part would be less
+likely to be overlooked if it included all the visible declarations.
+It might also facilitate the proposal to extract the private part into a
+separate file.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Monday, August 4, 2008  6:36 PM
+
+> > No.  In the proposal as written, private types and deferred 
+> > constants are only permitted in the pre-private visible part.
+> 
+> OK, but why?
+
+Because it would mean abandoning the linear elaboration/declaration model,
+perhaps?
+
+> It seems to me to be an unnecessary complication to propose that the 
+> rules for what's allowed in the trailing visible part be different (no 
+> private types or deferred constants) from the rules for the leading 
+> visible part.
+
+The rules aren't different. A private type must be completed in the
+trailing private part. Since there is no such part here, it cannot be
+completed and thus is always illegal. But the rules are unchanged.
+
+> There wouldn't seem to me to be any problem with privacy leakage or 
+> elaboration ordering, etc.  I understand that the trailing visible 
+> part is proposed to have no visibility on the private part, but I 
+> don't think that presents an obstacle, since the leading visible part 
+> doesn't have such visibility either, and it can declare private types 
+> and deferred constants with confidence that their full definition will 
+> appear in the private part.
+
+You think that "completion" before the thing being completed is not new?
+Janus/Ada processes declarations linearly, and having to check legal
+"completions" for private types would require duplicating quite a bit of
+code (especially as that code would have to ignore visibility rules).
+ 
+> The name "deferred" constants would be somewhat odd, for constants 
+> that are made visible in a trailing visible part, but that's more of a 
+> naming issue.  Maybe we should call them "hidden" constants instead of 
+> "deferred".
+
+As is the term "completion" for something that would happen before the declaration.
+ 
+> What I am getting at is that maybe we could simplify the proposed 
+> "sandwich" structure, and give the user the option of either a leading 
+> visible part or a trailing visible part, but not both in the same 
+> package.  This would have the advantage that the trailing visible part 
+> would be less likely to be overlooked if it included all the visible 
+> declarations.
+
+Seems like a dubious advantage to me. If this proposal gets at all complex,
+it's not going anywhere. The only reason for considering it is that it appears
+to be a simpler fix than any other. I would expect style guides to recommend
+to only put instances in the trailing public part (preferably nothing).
+
+> It might also facilitate the proposal to extract the private part into 
+> a separate file.
+
+I hope this latter proposal never gets off the ground; it would force all
+compilers into a source-based model where compiling of specs has no significant
+effect. Essentially, it would require all Ada compilers to work like GNAT,
+which seems bad from a diversity-of-implementations standpoint.
+
+****************************************************************
+
+From: Dan Eilers
+Date: Monday, August 4, 2008  8:14 PM
+
+> > OK, but why?
+>
+> Because it would mean abandoning the linear elaboration/declaration 
+> model, perhaps?
+
+Are you saying that certain declarations would have to be elaborated 
+out-of-order?  I don't see that.
+
+> The rules aren't different. A private type must be completed in the 
+> trailing private part. Since there is no such part here, it cannot be 
+> completed and thus is always illegal. But the rules are unchanged.
+
+I think we are in agreement that the consequences of what the rules allow
+would be different, even if the wording of the rules was exactly the same.
+I was hoping to eliminate the seemingly unnecessary difference in the
+consequences of the rules.
+
+> You think that "completion" before the thing being completed is not new?
+
+I said I didn't think it presented an obstacle.  It is already quite common
+to declare a full type in an inner scope, and subsequently export it using
+a derived type in an outer scope, which is conceptually very similar.
+
+> Janus/Ada processes declarations linearly, and having to check legal 
+> "completions" for private types would require duplicating quite a bit 
+> of code (especially as that code would have to ignore visibility rules).
+
+We process declarations linearly too, but I don't see the problem here.
+Instead of code duplication, you can probably achieve substantial code reuse.
+
+
+> > The name "deferred" constants would be somewhat odd, for constants 
+> > that are made visible in a trailing visible part, but that's more of 
+> > a naming issue.  Maybe we should call them "hidden" constants 
+> > instead of "deferred".
+>
+> As is the term "completion" for something that would happen before the 
+> declaration.
+
+Agreed.  "Completion" would be odd, but that seems to be a minor issue.
+
+
+> Seems like a dubious advantage to me. If this proposal gets at all 
+> complex, it's not going anywhere.
+
+I was actually trying to simplify things (two parts in a package instead of
+three).
+
+> > It might also facilitate the proposal to extract the private part 
+> > into a separate file.
+>
+> I hope this latter proposal never gets off the ground; it would force 
+> all compilers into a source-based model where compiling of specs has 
+> no significant effect.
+
+I don't follow this.  I was actually thinking that being able to put the
+private part first would make it easier to split the private part off
+into a separate source file, using existing compilation models.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Monday, August 4, 2008  9:28 PM
+
+...
+> > You think that "completion" before the thing being
+> completed is not new?
+> 
+> I said I didn't think it presented an obstacle.  It is already quite 
+> common to declare a full type in an inner scope, and subsequently 
+> export it using a derived type in an outer scope, which is 
+> conceptually very similar.
+
+Maybe to you, but not to me. The declaration of a new type is very different
+than the completion of the *same* type.
+
+> > Janus/Ada processes declarations linearly, and having to check legal 
+> > "completions" for private types would require duplicating quite a 
+> > bit of code (especially as that code would have to ignore visibility
+> > rules).
+> 
+> We process declarations linearly too, but I don't see the problem here.
+> Instead of code duplication, you can probably achieve substantial code
+> reuse.
+
+Only by a very massive restructuring of code; the code that processes private
+type declarations is completely separate from that processing full type
+declarations. I'm sure it would be possible and perhaps desirable to share code,
+but it surely would be a lot of work. It probably would be in your compiler, too.
+
+...
+> > Seems like a dubious advantage to me. If this proposal gets at all 
+> > complex, it's not going anywhere.
+> 
+> I was actually trying to simplify things (two parts in a package 
+> instead of three).
+
+True enough, but I don't think that can be done.
+
+> What I am getting at is that maybe we could simplify the proposed 
+> "sandwich" structure, and give the user the option of either a leading 
+> visible part or a trailing visible part, but not both in the same 
+> package.  This would have the advantage that the trailing visible part
+> would be less likely to be overlooked if it included all the visible
+> declarations.
+
+I should have mentioned this the last time, but that would be very limiting
+as to what you could put into the visible part.
+
+Let's take an example pulled from Claw:
+
+  package Claw.Trackbar is
+    type Trackbar_Type is new Claw.Scrolling.Root_Scroll_Type with private;
+
+    type Trackbar_Ticks_Type is (No_Ticks,
+                                 Bottom_Ticks, -- On right side for vertical trackbar
+                                 Top_Ticks,    -- On left side for vertical trackbar
+                                 Both_Side_Ticks);
+
+    type Trackbar_Slider_Type is (No_Slider, Fixed_Size, Auto_Size);
+
+    subtype Frequency_Subtype is Claw.Int range 0 .. Claw.Int'Last;
+
+    procedure Modify (
+        Trackbar   : in out Trackbar_Type;
+        Direction  : in Claw.Scrolling.Direction_Type;
+        Ticks      : in Claw.Trackbar.Trackbar_Ticks_Type
+                            := Claw.Trackbar.Bottom_Ticks;
+        Slider     : in Claw.Trackbar.Trackbar_Slider_Type
+                            := Claw.Trackbar.Auto_Size;
+        Tab_Stop   : in Boolean := True;
+        Allow_Selection_Range : Boolean := FALSE);
+
+     -- Many more routines.
+
+  private
+     type Trackbar_Type is new CLAW.Scrolling.Root_Scroll_Type with record
+        Ticks  : Claw.Trackbar.Trackbar_Ticks_Type;
+        Slider : Claw.Trackbar.Trackbar_Slider_Type;
+        ...
+     end record;
+  end Claw.Trackbar;
+
+Now, imagine that we wanted to export a Vector of trackbars. (This particular
+example is a little weird, but there are other Claw datatypes, such as tooltips,
+where there are operations defined on arrays and it would make sense for there
+to be operations defined on vectors as well.)
+
+Using Tucker's proposal, we would have something like:
+
+  package Claw.Trackbar is
+    type Trackbar_Type is new Claw.Scrolling.Root_Scroll_Type with private;
+
+    type Trackbar_Ticks_Type is (No_Ticks,
+                                 Bottom_Ticks, -- On right side for vertical trackbar
+                                 Top_Ticks,    -- On left side for vertical trackbar
+                                 Both_Side_Ticks);
+
+    type Trackbar_Slider_Type is (No_Slider, Fixed_Size, Auto_Size);
+
+    procedure Modify (
+        Trackbar   : in out Trackbar_Type;
+        Direction  : in Claw.Scrolling.Direction_Type;
+        Ticks      : in Claw.Trackbar.Trackbar_Ticks_Type
+                            := Claw.Trackbar.Bottom_Ticks;
+        Slider     : in Claw.Trackbar.Trackbar_Slider_Type
+                            := Claw.Trackbar.Auto_Size;
+        Tab_Stop   : in Boolean := True;
+        Allow_Selection_Range : Boolean := FALSE);
+
+     -- Many more routines.
+
+  private
+     type Trackbar_Type is new CLAW.Scrolling.Root_Scroll_Type with record
+        Ticks  : Claw.Trackbar.Trackbar_Ticks_Type;
+        Slider : Claw.Trackbar.Trackbar_Slider_Type;
+        ...
+     end record;
+  public
+     for Trackbar_Vectors is new Ada.Containers.Vectors (Trackbar_Type);
+     -- Define operations on Trackbar_Vectors here.
+  end Claw.Trackbar;
+
+I don't see any way to move this into a single trailing visible part, because we
+can't export things declared in the private part. Putting everything in the public part
+doesn't work:
+
+  package Claw.Trackbar is
+  private
+     type Trackbar_Type is new CLAW.Scrolling.Root_Scroll_Type with record
+        Ticks  : Claw.Trackbar.Trackbar_Ticks_Type; -- ERROR: not defined yet.
+        Slider : Claw.Trackbar.Trackbar_Slider_Type; -- ERROR: not defined yet.
+        ...
+     end record;
+  public
+    ... -- Combined visible parts from the previous package.
+  end Claw.Trackbar;
+
+and moving the declarations into the private part doesn't work either:
+
+  package Claw.Trackbar is
+  private
+     type Trackbar_Ticks_Type is (No_Ticks,
+                                  Bottom_Ticks, -- On right side for vertical trackbar
+                                  Top_Ticks,    -- On left side for vertical trackbar
+                                  Both_Side_Ticks);
+
+     type Trackbar_Slider_Type is (No_Slider, Fixed_Size, Auto_Size);
+
+     type Trackbar_Type is new CLAW.Scrolling.Root_Scroll_Type with record
+        Ticks  : Claw.Trackbar.Trackbar_Ticks_Type; -- OK.
+        Slider : Claw.Trackbar.Trackbar_Slider_Type; -- OK.
+        ...
+     end record;
+  public
+    type Trackbar_Type is new Claw.Scrolling.Root_Scroll_Type with private;
+
+    procedure Modify (
+        Trackbar   : in out Trackbar_Type;
+        Direction  : in Claw.Scrolling.Direction_Type;
+        Ticks      : in Claw.Trackbar.Trackbar_Ticks_Type
+                            := Claw.Trackbar.Bottom_Ticks; -- ERROR: Not visible.
+        Slider     : in Claw.Trackbar.Trackbar_Slider_Type
+                            := Claw.Trackbar.Auto_Size;    -- ERROR: Not visible.
+        Tab_Stop   : in Boolean := True;
+        Allow_Selection_Range : Boolean := FALSE);
+
+     -- Many more routines.
+     for Trackbar_Vectors is new Ada.Containers.Vectors (Trackbar_Type);
+     -- Define operations on Trackbar_Vectors here.
+  end Claw.Trackbar;
+
+You could declare the types private, but then you'd lose the fact that they are
+enumeration types and you have to declare a whole second set of literals as
+deferred constants -- that would be a maintenance hazard.
+
+You could restructure everything and pull those types into a separate package
+-- but that package would exist for no reason other than to avoid this
+all-or-nothing rule.
+
+Besides, the entire point of this proposal is to avoid wholesale restructuring.
+It is completely clear that you can write things like this, you just have to put
+various things into child (or unrelated) packages. So if you have to substantally
+restructure in order to use it, I don't think it really solves the problem.
+
+I suppose you could try to allow limited private leakage to fix this problem, but
+that seems like a slippery slope that leads straight to hell (semantic or methodological).
+
+> > > It might also facilitate the proposal to extract the private part 
+> > > into a separate file.
+> >
+> > I hope this latter proposal never gets off the ground; it would 
+> > force all compilers into a source-based model where compiling of 
+> > specs has no significant effect.
+> 
+> I don't follow this.  I was actually thinking that being able to put 
+> the private part first would make it easier to split the private part 
+> off into a separate source file, using existing compilation models.
+
+Maybe, but that would put substantial (new) restrictions on what could appear
+in the visible part of a package associated with such a private part.
+And I very much doubt that the people interested in this are going to settle
+for only leading private parts (after all, they want them now, and there is
+no such thing), so that is pretty much irrelevant.
+
+****************************************************************
+
+From: Edmond Schonberg
+Date: Tuesday, August 5, 2008  7:58 AM
+
+> > It might also facilitate the proposal to extract the private 
+> > part into a separate file.
+
+> I hope this latter proposal never gets off the ground; it would force all
+> compilers into a source-based model where compiling of specs has no
+> significant effect. Essentially, it would require all Ada compilers to work
+> like GNAT, which seems bad from a diversity-of-implementations standpoint.
+
+Placing the private part in a separate file is independent of the "end private"
+proposal, and has nothing to do with the source-model of compilation. But I
+fully agree with Randy: anything that affects the linear order of elaboration
+is a non-starter. The management of private parts permeates the front-end
+of the compiler, and any substantial change in this machinery is simply
+out of the question. The "end private" model can probably be incorporated
+without major surgery, but we won't know until we try to prototype it. So far,
+the only compelling reason for introducing the trailing visible part is to
+provide instantiations. We should stick to this circumscribed goal.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Tuesday, August 5, 2008  6:44 PM
+
+> Placing the private part in a separate file is independent of the "end
+private" proposal,
+
+Certainly true.
+
+> ...  and has nothing to do with the source-model of compilation.
+
+Definitely not true, at least in a practical sense.
+
+Such a proposal cannot be purely an "include" file like construct, because
+that would not have any place in the Ada standard. As Robert likes to say,
+iles do not appear anywhere in the Ada standard, so it isn't possible
+to talk about them in the standard. An implementation could do something
+like it, but it would be completely outside of the standard.
+
+So I'm presuming that any such language mechanism would look somewhat
+like a stub, and could be separately compiled presuming that the public
+part of the specification has already been compiled.
+
+Now, Janus/Ada is designed to compile individual source files, one at a time,
+containing one or more units, without any further restrictions than that
+the units with semantic dependencies must be compiled first. There is no
+naming requirements or other ordering requirements.
+
+Moreover, it's clear that there is not enough information in the public
+part alone to support any traditional compilation with it.
+
+Thus, some major changes to the compilation model would be needed to the
+Janus/Ada model in order to support separate private parts.
+
+One possible approach would be to support some sort of partial compilation
+for the public part. That (given that there is little useful information
+in such a part) would essentially be tokenizing the specfication for
+*real* compilation later with the private part. The net effect would be
+to design a whole new file structure for this. One could ask why bother?
+
+An alternative would be to drop the idea of single file at a time compilation.
+But that would require specifying many files and their relationships to
+the compiler, which would not be very user friendly. The only sane way
+to make that useable would be to require source file/unit naming to follow
+some standard model (or some equivalence in project files).
+But that is the essense of the source-model of compilation: compiling
+multiple files at a time to avoid saving partial intermediate results.
+
+I suppose some insane implementer might try to avoid source-model at
+all costs and make their compiler unusable or do three times as much work
+to implement it (I may in fact resemble that implementer :-), but the
+net effect is to essentially require the essense of source-model
+compilation for any new implementations that might exist. (Just like
+no new implementation would ever consider universal code sharing for
+generics). Real innovation does not come from the existing players, in
+general.
+
+Of course, the real question is what precisely is this supposed feature
+supposed to be helping? One of the main reasons for making private packages
+useful with "private with" was to allow them to be used in private parts,
+making version control of private alternatives much easier. I could see
+separate private parts being used for handling alternatives, but private
+packages are better. (And none of these solutions are a full solution to
+alternatives.) So it's not at all clear to me that there are compelling
+reasons for such a feature.
+
+Which is all off-topic here anyway.
+
+****************************************************************
+
+From: Dan Eilers
+Date: Tuesday, August 5, 2008  1:50 AM
+
+Your example is compelling that two parts are insufficient.
+But I think by extension it is equally compelling that three parts,
+or any finite number, are insufficient as well.
+
+Suppose in some package you want a public enumeration type T1, and
+a private record T2 with a field of type T1, and a public vector T3
+of the private record T2, and another private record T4 with a field
+of the public vector T3, and another public vector T5 of the private
+record T4.
+
+Won't this require a 5-part package, with T1 in the first public part,
+T2 in the first private part, T3 in the second public part, T4 in the
+second private part, and T5 in the third public part?
+
+****************************************************************
+
+From: Tucker Taft
+Date: Tuesday, August 5, 2008  9:38 AM
+
+    You are making a different proposal, in my view.
+Feel free to do so, but the one I made is definitely
+one where completions continue to follow the partial
+view.  I find your suggestion confusing and inconsistent
+with other parts of the language, but if you want
+to write up something, that's fine.  But it is definitely
+not something I would want to include in this "end private"
+AI.  It seems like one of those ideas that can kill a proposal
+by making it at least appear more complicated than most
+people can stomach.
+ 
+****************************************************************
+
+From: Dan Eilers
+Date: Tuesday, August 5, 2008  5:45 PM
+
+> But it is definitely not something I would want to include in this 
+> "end private" AI.
+
+I think the existing AI would benefit from a little better reasoning
+in the first paragraph of the !proposal where it says:
+
+> In the "post-private" visible part, no new private views nor deferred 
+> constants may be declared, as there would be no place to complete them.
+
+Such private views or deferred constants _could_ in fact be "completed"
+in the preceding private part, if we wanted to allow that.
+
+Randy and Ed have both referred to abandoning the linear
+elaboration/declaration model, but it's not at all clear to me that
+this change would cause any elaboration difficulties.  If there are
+such difficulties, then maybe the AI should point those out as the
+reason for not allowing private views or deferred constants in the
+trailing visible part.
+
+> I find your suggestion confusing and inconsistent with other parts of 
+> the language, ...
+
+Yes, it's certainly inconsistent with longstanding terminology such
+as "deferred" constants, which implies that the full definition is
+coming later.  But that's just a terminology issue.  The essence of
+a deferred constant is not that its partial view is provided textually
+earlier than its full view, but that it _has_ a partial view.  If
+deferred constants had originally been called "opaque" constants,
+I don't think providing the partial view textually later than the
+full view, but in an outer scope, would be confusing.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Tuesday, August 5, 2008  6:20 PM
+
+> Won't this require a 5-part package, with T1 in the first public part,
+> T2 in the first private part, T3 in the second public part,
+> T4 in the second private part, and T5 in the third public part?
+
+I tend to agree. We all know the rule about having zero, one, or many
+of something. Clearly, this proposal as written fails that rule. One reason
+that I'm not very excited about this proposal is the feeling that it
+eventually will morph into an unlimited number of such parts, with
+the loss of readability (and implementation complexity) that that entails.
+
+But we do have to avoid FUD and "slippery slope" arguments by themselves.
+The current single part proposal doesn't really have those problems, and
+it does solve the instantiation problem in a useful way.
+
+Note that if we were willing to abandon the linear elaboration/linear
+freezing model, we probably already would have solved this with a no-freeze
+instantiation. Or we could keep the visible part together by having a
+deferred part that logically comes after the private part but is written
+before it. But both of these would add a huge amount of new complexity
+to compilers to solve a problem which can be (less conviniently) solved
+with existing language constructs. The search here is to find a solution
+that allows convinient solving of the problem without too much
+implementation or conceptual pain.
+
+****************************************************************
+
+From: Tucker Taft
+Date: Tuesday, August 5, 2008  7:55 PM
+
+    Calling this just a "terminology" issue reflects how differently
+we see this.  I am not worried about terminology.  I am worried
+about the way the typical Ada programmer thinks about the
+world.  I know when moving to Java, one of the things I find
+the most confusing is that references can come before definitions
+to fields of a class.  Yes, you can get used to it, but it is
+most definitely not just a "terminology" issue.  It is a completely
+different mind set.
+
+****************************************************************
+
+From: Dan Eilers
+Date: Tuesday, August 5, 2008  8:26 PM
+
+> I know when moving to Java, one of the things I find the most 
+> confusing is that references can come before definitions to fields of a class.
+
+I'm not sure if you were using this just as an example, or if you
+understood my proposal to involve references before definitions.
+I didn't intend it to.
+
+I was proposing to change your example:
+
+   package Abc is
+       type T is private;
+       Null_T : constant T;
+
+     private
+         type T is new Integer;
+         Null_T : constant T := 0;
+     end private;
+
+       package Lists_Of_T is new Generic_Lists(T);
+       type T_List is new Lists_Of_T.List;
+
+   end ABC;
+
+to:
+
+   package Abc2 is
+
+     private
+         type T is new Integer;
+         Null_T : constant T := 0;
+     end private;
+
+       type T is private;       -- moved here
+       Null_T : constant T;     -- moved here
+
+       package Lists_Of_T is new Generic_Lists(T);
+       type T_List is new Lists_Of_T.List;
+
+   end ABC2;
+
+where everything is elaborated in the order declared, and nothing is
+referenced before being fully defined.
+
+Yes, there is somewhat of a shift in mind set because the reader sees
+the full definition of type T before they see that T is exported.
+But that doesn't seem too different from the way pragma export makes
+something externally visible after its full definition is seen.
+
+btw, I'm much less enthusiastic about this option now that Randy has
+shown a realistic case where this still wouldn't be adequate.
+
+****************************************************************
+
+From: Tucker Taft
+Date: Wednesday, August 6, 2008  4:18 PM
+
+Thanks for elaborating.  I understand what you are trying to accomplish.
+It is somewhat analogous to the way Modula 3 works, where you partially
+"reveal" properties of a type in a spec, separately from an implementation
+where you define the type.  It could be an elegant model.  However, I
+see it as too big a shift for Ada.
+
+I am trying to solve a problem I have run into
+*many* times with minimal disruption to the Ada private-type model.
+You are suggesting an approach that would really make more sense in
+a completely new language.  One of Bob Duff's ideas (if I remember it
+correctly) was to eliminate all elaboration from specs, and thereby
+eliminate all linear-elaboration order restrictions from them.
+I think that has some real appeal, but it ain't Ada.
+
+Bob might want to "elaborate" further... ;-)
+
+****************************************************************
+
+From: Dan Eilers
+Date: Wednesday, August 6, 2008  11:24 AM
+
+> I tend to agree. We all know the rule about having zero, one, or many 
+> of something. Clearly, this proposal as written fails that rule. One 
+> reason that I'm not very excited about this proposal is the feeling 
+> that it eventually will morph into an unlimited number of such parts, 
+> with the loss of readability (and implementation complexity) that that entails.
+
+Maybe having an unlimited number isn't all that bad.
+We already allow an unlimited number of private regions inside a
+package spec, since we allow nested package specs, each with its own
+private part.  And similarly within the statement_list of a subprogram
+we allow an unlimited number of declare blocks to add more declarations.
+
+We could use the "declare" keyword in a private part to mean we are
+restarting the visible region, which would avoid the issue of whether
+or not to put a semicolon after the somewhat awkward "end private".
+
+From a user's perspective, I think adding the ability to restart the
+visible region is conceptually simpler than adding a new kind of
+non-freezing instantiation.  It may also be simpler to describe in the RM
+and simpler to implement.
+
+****************************************************************
+
+From: Tucker Taft
+Date: Thursday, August 7, 2008  5:57 AM
+
+The proposal explained why it only allows having one private part.
+I don't see that changing, and I would personally resist it.
+
+****************************************************************
+
+From: Dan Eilers
+Date: Thursday, August 7, 2008  12:40 PM
+
+I can live with that, but I don't find the argument compelling, and
+it goes against the history of programming language development.
+
+In Pascal, Wirth thought it would be adequate to have a region of
+constants, followed by a region of type declarations, followed by a
+region of variable declarations, followed by a region of subprogram
+declarations.  This was probably inspired by Cobol's ordering of
+Identification Division, Environment Division, Data Division, and
+Procedure Division.
+
+This was found to be inadequate, and Ada83 did away with Const regions,
+Type regions, and Var regions, allowing individual declarations to be freely
+interspersed, but kept the restriction that basic_declarative_items
+must come before later_declarative_items.
+
+This was also found to be inadequate, and Ada95 eliminated this
+restriction, allowing interspersing individual variable declarations with
+body declarations, but kept the restriction that in package specs,
+visible declarations must come before private declarations.
+
+This was also found to be inadequate.
+
+In each case the argument was made that the language is easier for a
+human to read and easier for a compiler to process if ordering restrictions
+are enforced, and textbook examples work perfectly well with such
+restrictions.  But real-world programs, including programs automatically
+translated from other languages, eventually run into difficulties.
+
+The proposal makes the argument that if you allow more than one private part,
+then you need to know which private types are completed in which private
+part.  This isn't compelling because simply requiring a private type or
+deferred constant to be completed in the immediately following private part
+would satisfy this objection.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Thursday, August 7, 2008  1:23 PM
+
+I suspect that it would not be too hard to construct an example where that
+would be too limiting also.
+
+The real question is whether the added capabilities by allowing
+multiple parts are really worthwhile enough to support.
+
+My guess is that (presuming we adopt this proposal at all) we'll start with
+one extra part, and then sometime down the road expand it to include more.
+But it is important to remember that at some point, a designer really does
+need to split this stuff into separate packages: a package shouldn't contain
+bunches of loosely related types. "private with" and "limited with" were
+added specifically to make having many packages easier. So it not that
+clear that we really need to handle packages with many private types (with
+the corresponding need for many private parts).
+
+****************************************************************
+
+From: Tucker Taft
+Date: Thursday, August 7, 2008  8:01 PM
+
+I think there is something elegant about sandwiching a private part in between
+two visible parts.  When you start to have a random alternation between visible
+and private, you have a jumble rather than an "abstraction."
+Remember we are talking here about a "specification"
+not the implementation.
+
+I understand your point about the Pascal restriction which required grouping
+constants, variables, etc., which proved to be undesirable, but I think that
+was more because Ada started supporting arbitrary computation in the
+initialization expressions of variables and constants.  On the other hand,
+I much prefer Ada's rules requiring a specific ordering of reserved words
+when you have a sequence.  I find the looseness of C and C++ not at all
+helpful in terms of where "const," "static," etc., may appear within a
+declaration.  It makes it much harder to read other people's code.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Thursday, August 7, 2008  8:34 PM
+
+You have a strange idea about "elegant". I think Bob has complained that the
+private part is a hack, and there surely is some sense to that view. This
+second visible part is then just doubling the hack, it's surely not elegant.
+
+But you seem to have a very different view about the meaning of the private part
+than I do. When you start indenting it further than the rest of the package,
+effectively treating it as some nested thing, you've lost me completely. I see
+it as *only* about visibility; otherwise, it is just a normal part of the
+package. Extra indentation means to me extra naming is needed (I almost never
+use use clauses), and that is not true for private parts. This apparent
+different view worries me, because it may mean that we aren't on the same
+page about this very basic feature. And that will make it harder to agree
+on how to change it (if at all).
+
+It's pretty hard for anything that doesn't meet the zero-one-many rule to be
+elegant. I'd be happy to call the trailing visible part idea "clever", as I
+haven't been able to poke major holes in it, and it seems to solve a number
+of problems without too much disruption to the language semantics. (I very
+much doubt that compilers will be as lucky, but that's a different issue.)
+But not elegant.
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent