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

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

--- ai05s/ai05-0074-2.txt	2010/04/03 00:23:48	1.6
+++ ai05s/ai05-0074-2.txt	2010/04/29 06:27:42	1.7
@@ -115,7 +115,7 @@
 the private part may be specified (with "end private;") and thereafter
 additional visible declarations may be provided. 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. 
+declared, as there would be no place to complete them.
 
 When there is an "end private;" we might recommend that the declarations
 in the private part be indented.  For example:
@@ -123,17 +123,17 @@
    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;
-    
+
 Allowing visible declarations after the private part allows generic
 instantiations and other constructs that freeze a private type (such as
 record extensions or variable declarations), to appear within the same
@@ -151,7 +151,7 @@
 
 Replace 7.1(3) with the following:
 
-  package_specification ::= 
+  package_specification ::=
      package defining_program_unit_name is
         {basic_declarative_item}
       [private
@@ -159,7 +159,7 @@
       [end private;
         {basic_declarative_item}]]
      end [[parent_unit_name.]identifier]
-     
+
 Modify 7.1(6/2) as follows:
 
    The first list of basic_declarative_items {and optional third list of
@@ -172,7 +172,7 @@
    has an implicit empty private part.] Each list of basic_declarative_
    items of a package_specification forms a declaration list of the
    package.
-   
+
 Modify 7.3(4) as follows:
 
    A private_type_declaration or private_extension_declaration declares
@@ -184,22 +184,22 @@
    declared by the full_type_declaration is called the full view.] A
    generic formal private type or a generic formal private extension is
    also a partial view.
-   
+
      TBD: Is it OK to refer to the "first declaration list of the visible
           part of a package"?  Does that work for generic packages, or
           is the first declaration list the formal part?  Do we need to
           say "first list of basic_declarative_items of the visible part
           of the package"?  Same question applies for deferred constants
           in 7.4(3).
-          
+
 Modify 7.4(3) as follows:
 
    A deferred constant declaration that is completed by a full constant
    declaration shall occur immediately within {the first declaration
    list of} the visible part of a package_specification. For this case,
    the following additional rules apply to the corresponding full
-   declaration: 
-   
+   declaration:
+
 Add after 8.2(2):
 
    * The immediate scope of a declaration in the private part of a package
@@ -213,7 +213,7 @@
      For a generic package, it also includes the first list {and optional
      third list} of basic_declarative_items of the package_specification.
      For a generic subprogram, it also includes the profile.
-   
+
 Modify 8.2(9) as follows:
 
    * [Redundant: The visible part of a package, task unit, or protected unit
@@ -231,7 +231,7 @@
 a container generic), with a private type as one of the actual
 parameters to the instantiation. Another problem is a desire
 to export a variable of a private type. This is not permitted
-prior to the private type being completed.  
+prior to the private type being completed.
 
 A third problem is best illustrated by an example:
 
@@ -269,7 +269,7 @@
              ...
          end record;
      end Constructs;
-     
+
 Here we want to define a nested generic package that exports a private
 extension of the private type Root_Construct_Handle. Everything is fine
 until we get to the private part of this nested generic, and we realize
@@ -309,14 +309,14 @@
 visible part roughly like the visible part of a child, by starting from
 scratch and building up the visibility that corresponds to that which a
 (public) child unit sees, rather than trying to "remove" declarations
-from the existing visibility at the end of the private part.  
+from the existing visibility at the end of the private part.
 
 Another possible approach might be to treat the private part roughly
 like a nested construct, where the visibility is "pushed" before the
 private part, and then "popped" afterward. Prior to popping the private
 part visibility, it would want to be "saved" so that when it is wanted
 again, such as in the package body, or in the private part of some
-child, it can be restored. This kind of "save" might be similar to 
+child, it can be restored. This kind of "save" might be similar to
 what is done with subunit "stubs."
 
 Ada 2005 WORKAROUNDS
@@ -371,7 +371,7 @@
    package Expressions.Sequences is
        package Expr_Sequences is new Sequences(Expr_Ref);
        type Sequences is new Expr_Sequences.Sequence;
-   end Expressions.Sequences;   
+   end Expressions.Sequences;
 
 Here, besides the extra with clause, we need to declare an extra type
 simply so that the type is visible to the limited with clause (which
@@ -393,13 +393,13 @@
              ...
           end record;
       end private;
-      
+
         package Signature is new Set_Signature(Elem, Set);
 
     end Hashed_Sets;
-    
+
 Here is an example where we want to instantiation a container:
-    
+
     package Expressions is
         type Expr_Ref is private;
 
@@ -414,16 +414,16 @@
           type Expression;  -- completion deferred to body
           type Expr_Ref is access Expression;
       end private;
-      
+
         package Expr_Sequences is new Sequences(Expr_Ref);
-        type Expr_Seq is new Expr_Sequences.Sequence;  
+        type Expr_Seq is new Expr_Sequences.Sequence;
           -- completion of incomplete type
-        
+
    end Expressions;
 
-    
+
 Here is the nested generic with a private extension:
-    
+
      package Constructs is
          type Root_Construct_Handle is abstract tagged private;
 
@@ -441,7 +441,7 @@
                ...
            end record;
        end private;
-       
+
          generic
              type Data_Part is private;
          package Handles is
@@ -459,9 +459,9 @@
                  -- ERROR: Parent type of record extension
                  --        must be completely defined.
          end Handles;
-       
+
      end Constructs;
-         
+
 
 !ACATS test
 
@@ -616,7 +616,7 @@
 
 > It seems to me that the most important case is where there is some mutual
 > recursion going on, such as:
-> 
+>
 >     with Ada.Containers.Vectors; use Ada.Containers;
 >     package Trees is
 >         type Tree is private;
@@ -689,7 +689,7 @@
 > > because clients have to 'with' it, but it doesn't prevent you from doing
 > > anything.  The mutually recursive case, on the other hand, requires massive
 > > restructuring to work around the restriction.
-> 
+>
 > The one place where putting the instantiation in the child
 > doesn't really work is when you are trying to include
 > the instantiation of, say, a signature package within a generic.
@@ -716,8 +716,8 @@
 > By the way, the "end with" syntax is, well..., it will take some "getting used"
 > to.  If I see "end" (especially at the beginning of a line) I think "this is
 > the end of something".
-> 
-Hmmm... since the effect is to automatically with the children, what 
+>
+Hmmm... since the effect is to automatically with the children, what
 about "with all" ?
 
 (Designing new syntax is always great fun :-)
@@ -771,7 +771,7 @@
 From: Jean-Pierre Rosen
 Date: Monday, October 1, 2007  3:23 AM
 
-And how would it be different from a child package, apart from not 
+And how would it be different from a child package, apart from not
 seeing the private part of the parent?
 
 ****************************************************************
@@ -818,13 +818,13 @@
 From: Edmond Schonberg
 Date: Monday, October 1, 2007  3:22 PM
 
-A smaller syntactic change would be to have both views of the type in  
+A smaller syntactic change would be to have both views of the type in
 a single declaration:
 
 private type Tree is record ...
 
-You can have as many of those as you want, which answers the "zero,  
-one, infinity" rule.   Full "private sections" would sit heavily on  
+You can have as many of those as you want, which answers the "zero,
+one, infinity" rule.   Full "private sections" would sit heavily on
 my stomach (and Randy's too, I recall).
 
 ****************************************************************
@@ -883,7 +883,7 @@
         ... -- private stuff
     end private;
         ... -- public stuff
-    end P;    
+    end P;
 
 ?
 
@@ -997,36 +997,36 @@
 >idea - it was only the broadly defined version that didn't work). Ed's idea
 >also would work (although it has the issue of exposing the implementation in
 >practice even if not semantically).
-  
 
-I think that the end private (with or without semicolon) is conceptually 
-the easiest for users to master.  I do think though that a restricted 
-version of that proposal would be a lot easier to both implement and 
-understand.  First yes, it would be possible to have multiple private 
-parts, but is that game really worth the candle?  If you have ONE 
-private part, then private types have to be declared before the private 
-part, along with deferred constants and so on.  If we hang the 
-elaboration of child units then the package body right at the end of the 
-private part--or the package declaration if there isn't one--then 
-instantiations of children there are fine.  As for making private 
-details visible, no reason it should.  What you care about is that 
-private types, and for that matter subprograms in the (first) public 
+
+I think that the end private (with or without semicolon) is conceptually
+the easiest for users to master.  I do think though that a restricted
+version of that proposal would be a lot easier to both implement and
+understand.  First yes, it would be possible to have multiple private
+parts, but is that game really worth the candle?  If you have ONE
+private part, then private types have to be declared before the private
+part, along with deferred constants and so on.  If we hang the
+elaboration of child units then the package body right at the end of the
+private part--or the package declaration if there isn't one--then
+instantiations of children there are fine.  As for making private
+details visible, no reason it should.  What you care about is that
+private types, and for that matter subprograms in the (first) public
 part are now elaborated.
 
-Would there be some confusion from the fact that declarations in the 
-second public part would not be visible in the body?  Not that much.  
-Would it be a problem?  I'd have to do some experimentation, but I don't 
-see it as a problem.  You might have to put some declarations in a child 
-package then use renaming in the second public part to make them visible 
-as part of the main package API.  I have to think that in most cases 
+Would there be some confusion from the fact that declarations in the
+second public part would not be visible in the body?  Not that much.
+Would it be a problem?  I'd have to do some experimentation, but I don't
+see it as a problem.  You might have to put some declarations in a child
+package then use renaming in the second public part to make them visible
+as part of the main package API.  I have to think that in most cases
 that will be what you want to do anyway.
 
-Now to explain some magic handwaving above.  How do you tell that a 
-reference in the second private part is to a child package?  Either a 
-with clause, a use clause, or both in the second public part.  Allowing 
-with clauses there is much more like the two part package declarations, 
-but a bit easier to maintain.  I'd like to limit it to use clauses for 
-child units for methodological reasons, but such units could have their 
+Now to explain some magic handwaving above.  How do you tell that a
+reference in the second private part is to a child package?  Either a
+with clause, a use clause, or both in the second public part.  Allowing
+with clauses there is much more like the two part package declarations,
+but a bit easier to maintain.  I'd like to limit it to use clauses for
+child units for methodological reasons, but such units could have their
 own with clauses for anything, so that would not limit much in reality.
 
 ****************************************************************
@@ -1054,25 +1054,25 @@
 From: Jean-Pierre Rosen
 Date: Monday, October 1, 2007  3:16 AM
 
-> A smaller syntactic change would be to have both views of the type in a 
+> A smaller syntactic change would be to have both views of the type in a
 > single declaration:
-> 
+>
 > private type Tree is record ...
 
 Except of course that it would be ambiguous:
     private
         type Tree is ...
 
-The more I think about the "end private" idea, the more uncomfortable I 
+The more I think about the "end private" idea, the more uncomfortable I
 feel. I'm afraid there is a huge can of worms sleeping under it...
 
 For example:
 Child units currently see *the* private part. Would they see all of them?
 
-If I put a "use" clause in a private part, does it extend into the 
+If I put a "use" clause in a private part, does it extend into the
 following non-private parts?
 
-How would the "private with" work? It should apply to all private parts, 
+How would the "private with" work? It should apply to all private parts,
 therefore we'll have visibility coming in and out...
 
 ****************************************************************
@@ -1080,12 +1080,12 @@
 From: Pascal Leroy
 Date: Tuesday, October 2, 2007  8:00 PM
 
-> Bob makes the point that the "end private" idea is more 
-> powerful, in that you can use items from the instantiation to 
-> visibly complete incomplete types declared before the 
-> instantiation.  When trying to create mutually recursive 
+> Bob makes the point that the "end private" idea is more
+> powerful, in that you can use items from the instantiation to
+> visibly complete incomplete types declared before the
+> instantiation.  When trying to create mutually recursive
 > types, that seems pretty important.
-> 
+>
 >      package Trees is
 >          type Tree is private
 >          ...
@@ -1116,9 +1116,9 @@
 From: Pascal Leroy
 Date: Tuesday, October 2, 2007  8:01 AM
 
-> I still think this is a bad idea; I still think that two part 
-> instantiations can work if sufficiently limited (we never 
-> really finished working on that idea - it was only the 
+> I still think this is a bad idea; I still think that two part
+> instantiations can work if sufficiently limited (we never
+> really finished working on that idea - it was only the
 > broadly defined version that didn't work).
 
 I agree with this.  I always thought that we were on the right track, but we
@@ -1218,25 +1218,25 @@
 
 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
@@ -1247,14 +1247,14 @@
 >        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;
@@ -1264,7 +1264,7 @@
 >     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.
@@ -1293,7 +1293,7 @@
 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. :-(
 
@@ -1358,11 +1358,11 @@
 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 
+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
@@ -1512,7 +1512,7 @@
 entity is required.
 
 > The purpose of privacy is to hide things from OTHER packages, not from the
-> package itself.  
+> package itself.
 
 If that were true, then why wouldn't the visible part of
 a child package have visibility on the private part of
@@ -1531,14 +1531,14 @@
 the visibility after "end private;".
 
 > ...  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.
@@ -1584,7 +1584,7 @@
 ...
 > > The purpose of privacy is to hide things from OTHER packages, not from the
 > > package itself.
-> 
+>
 > If that were true, then why wouldn't the visible part of
 > a child package have visibility on the private part of
 > its parent?
@@ -1605,7 +1605,7 @@
 > > 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.
-> 
+>
 > The basic C++ "protection" model is quite different from
 > Ada's.  "Private" declarations are just as "visible" as
 > "public" declarations, but you get an error if you try
@@ -1622,7 +1622,7 @@
 
 >> What are the properties of subtype S?  I
 >> really think it needs to still be private.
-> 
+>
 > You may well be right, but I'd like to understand why.  What if S is an integer
 > type?  Would that cause the sky to fall?
 
@@ -1639,7 +1639,7 @@
 the private part of the package and not have to
 worry about the semantic effects on clients of
 the package.
- 
+
 > Or, what if S is an integer type within this package, but when viewed from
 > outside, it is private?  There's a "+" implicitly declared in the private part;
 > what if it's visible in the second visible part, but not visible in clients?
@@ -1653,7 +1653,7 @@
 >> If that were true, then why wouldn't the visible part of
 >> a child package have visibility on the private part of
 >> its parent?
-> 
+>
 > I must admit, I've never quite understood the high-level rationale for that.
 > If the so-called "leakage" is explicit in the program text, what's the harm?
 > I suppose the devil's in the details...
@@ -2110,7 +2110,7 @@
 which would use only the thunks it really needed for the elaboration
 of the spec, and one for the body, which would use the remaining thunks.
 
-> 
+>
 > The privacy breaking is uncomfortable, mainly because it could easily mean
 > that generics like the containers may not be usable in specifications
 > depending on their implementation. That suggests that we'd have to add a
@@ -2182,7 +2182,7 @@
 >proposals, but at least with it you can write the sort of things he wants to
 >(as opposed to the current situation where it is nearly impossible).
 
-With my Norm Cohen Halloween costume on, and tongue very firmly in 
+With my Norm Cohen Halloween costume on, and tongue very firmly in
 cheek, might I suggest:
 
      package Inst is not private new Gen(Priv) with limited;
@@ -2195,20 +2195,20 @@
 
          not private package Inst is not limited new Gen(Priv);
 
-Am I being silly here?  A bit.  But the first case seems to map almost 
-directly to the multiple private part model.  As I see it, the problems 
-there come from exporting types and declarations in the private part, by 
-a renaming, derived type, or subtype in the generic package 
-specification. In one sense we are trying to poke holes in the privacy 
-screen, so it seems unfair to talk about unintended holes that a 
-programmer can avoid.  On the other hand, the Ada philosophy is to make 
+Am I being silly here?  A bit.  But the first case seems to map almost
+directly to the multiple private part model.  As I see it, the problems
+there come from exporting types and declarations in the private part, by
+a renaming, derived type, or subtype in the generic package
+specification. In one sense we are trying to poke holes in the privacy
+screen, so it seems unfair to talk about unintended holes that a
+programmer can avoid.  On the other hand, the Ada philosophy is to make
 such things explicit.
 
-So maybe we are looking in the wrong place.  We know what we want: to be 
-able to export generic instamces which are not child packages but can 
-see into the private part.  If we flag the generic for export in some 
-way, it may be that we want to flag any otherwise private types, 
-subprograms, or whatever that such a generic can make visible outside 
+So maybe we are looking in the wrong place.  We know what we want: to be
+able to export generic instamces which are not child packages but can
+see into the private part.  If we flag the generic for export in some
+way, it may be that we want to flag any otherwise private types,
+subprograms, or whatever that such a generic can make visible outside
 the private part.
 
 Taking off the Norm Cohen costume, something like:
@@ -2234,17 +2234,17 @@
 end Foo;
 
 
-Seems to me we avoid most of the potential issues this way.  Yes, you 
-can use this mechanism to break privateness.  But then again, unless 
-someone is holding a gun, or the software equivalent, to the 
-programmer's head, there is no requirement to make any particular type 
+Seems to me we avoid most of the potential issues this way.  Yes, you
+can use this mechanism to break privateness.  But then again, unless
+someone is holding a gun, or the software equivalent, to the
+programmer's head, there is no requirement to make any particular type
 private, or to even have any private types at all.
 
-For the package FuBar, the export keyword (or whatever syntax is chosen) 
-has  semantic consequences:  The visibility of the unit is increased.  
-For non-generic objects, types, or subprograms, all the notation does is 
-flag that they can be used in such quasi-public instantiations.  Or you 
-could take the view that it also expands the visibility: into the 
+For the package FuBar, the export keyword (or whatever syntax is chosen)
+has  semantic consequences:  The visibility of the unit is increased.
+For non-generic objects, types, or subprograms, all the notation does is
+flag that they can be used in such quasi-public instantiations.  Or you
+could take the view that it also expands the visibility: into the
 generic_actual_part of an exported generic instantiation.
 
 ****************************************************************
@@ -2800,14 +2800,14 @@
 > instantiation is written. That seems bad: it's not uncommon to use an
 > instantiation to get a body elaborated in a spec (Ada provides no other way
 > to do that). So, given a generic like:
-> 
+>
 >      generic
 >          type Foo (<>) is ...
 >      package Bar is
 >          package Nested is new <some generic> (Foo);
 >          subtype Bounds is Integer range 1 .. Nested.Func;
 >      end Bar;
-> 
+>
 > A partial instantiation of Bar would raise Program_Error on the call of
 > Nested.Func (because the body is not elaborated) but would work correctly
 > for a normal instantiation. That's unpleasant.
@@ -2849,7 +2849,7 @@
 >> by the generic instance in the full definition of
 >> a private type passed as the actual, since it can't
 >> create a circularity.
-> 
+>
 > But the real problem is that you haven't addressed the anomalies that Steve
 > and Erhard pointed out the last time we discussed this (and that effectively
 > killed it). The problem was that a lot of partially defined stuff
@@ -2895,7 +2895,7 @@
 > instantiation") is never going to work. I've been trying to make the
 > "limited instantiation" more acceptable, but I haven't gotten any real
 > feedback from you.
-> 
+>
 > I realize that some people don't like the idea for some reason; what I'd
 > like to find out is what about the proposal is disliked so that it can be
 > enhanced. (I'm convinced that it would be best to start with a mechanism
@@ -3085,7 +3085,7 @@
 Date: Monday, October 22, 2007 10:13 PM
 
 > Quoting from the Atlanta minutes:
-> 
+>
 > "Tucker has changed the freezing rules to require freezing at the end of an
 > instance and then have piecemeal instantiation. This is necessary so a type
 > can contain a component of its own type. Pascal objects that this is a
@@ -3096,7 +3096,7 @@
 > package problem is also covered even without piecemeal freezing. Randy notes
 > that we could still allow this in 2015 if it actually proves to be
 > important."
-> 
+>
 > And now you are reintroducing this again - some ideas just never die.
 
 It may *sound* the same, but it really isn't.  This is
@@ -3117,13 +3117,13 @@
 From: Jean-Pierre Rosen
 Date: Wednesday, October 24, 2007 11:06 AM
 
-I've been following this thread, and I must say I am worried by the 
+I've been following this thread, and I must say I am worried by the
 complexity, from a user's point of view, of all the solutions presented.
 
-In short: only members of the ARG will be able to use that. Casual users 
-already know very few about the real possibilities of the language (OK, 
-that's what makes our business as consultants). I doubt that they will 
-find out the appropriate spell if they want to instantiate a generic on 
+In short: only members of the ARG will be able to use that. Casual users
+already know very few about the real possibilities of the language (OK,
+that's what makes our business as consultants). I doubt that they will
+find out the appropriate spell if they want to instantiate a generic on
 a private type (the real need).
 
 The only acceptable solution is to allow:
@@ -3134,10 +3134,10 @@
 
     package Inst is new Gen (T);
 
-and nothing else. Can it be done? For example, decide that in this case 
-actual instantiation does not happen logically at the place where it is 
-declared, but immediately after the full declaration of T. But of course 
-the visibility of the instantiation would be public. No use of the 
+and nothing else. Can it be done? For example, decide that in this case
+actual instantiation does not happen logically at the place where it is
+declared, but immediately after the full declaration of T. But of course
+the visibility of the instantiation would be public. No use of the
 instance would be allowed until it is "logically" instantiated.
 
 Am I pipe-dreaming here?
@@ -3147,17 +3147,17 @@
 From: Edmond Schonberg
 Date: Wednesday, October 24, 2007  2:06 PM
 
-> I've been following this thread, and I must say I am worried by the  
-> complexity, from a user's point of view, of all the solutions  
+> I've been following this thread, and I must say I am worried by the
+> complexity, from a user's point of view, of all the solutions
 > presented.
 
 You can add:  "and from the implementor's point of view".
 
 >
-> In short: only members of the ARG will be able to use that. Casual  
-> users already know very few about the real possibilities of the  
-> language (OK, that's what makes our business as consultants). I  
-> doubt that they will find out the appropriate spell if they want to  
+> In short: only members of the ARG will be able to use that. Casual
+> users already know very few about the real possibilities of the
+> language (OK, that's what makes our business as consultants). I
+> doubt that they will find out the appropriate spell if they want to
 > instantiate a generic on a private type (the real need).
 >
 > The only acceptable solution is to allow:
@@ -3168,22 +3168,22 @@
 >
 >    package Inst is new Gen (T);
 >
-> and nothing else. Can it be done? For example, decide that in this  
-> case actual instantiation does not happen logically at the place  
-> where it is declared, but immediately after the full declaration of  
-> T. But of course the visibility of the instantiation would be  
-> public. No use of the instance would be allowed until it is  
+> and nothing else. Can it be done? For example, decide that in this
+> case actual instantiation does not happen logically at the place
+> where it is declared, but immediately after the full declaration of
+> T. But of course the visibility of the instantiation would be
+> public. No use of the instance would be allowed until it is
 > "logically" instantiated.
 
-I agree that for a new language design the only reasonable solution  
-would be to allow types with only partial views to appear as actuals.  
-However, as was mentioned repeatedly, any change to the freezing  
-rules is extremely disruptive. It is nothing we would be willing to  
-do without a very VERY strong user demand, and that is at present  
-totally absent.  If  Ada2005 programmers start using containers in  
-more ambitious forms maybe they will find it convenient to have the  
-premature instantiations that have motivated this AI. In the  
-meantime, there is no harm in exploring other designs, but we may  
+I agree that for a new language design the only reasonable solution
+would be to allow types with only partial views to appear as actuals.
+However, as was mentioned repeatedly, any change to the freezing
+rules is extremely disruptive. It is nothing we would be willing to
+do without a very VERY strong user demand, and that is at present
+totally absent.  If  Ada2005 programmers start using containers in
+more ambitious forms maybe they will find it convenient to have the
+premature instantiations that have motivated this AI. In the
+meantime, there is no harm in exploring other designs, but we may
 have more pressing things to fix.
 
 ****************************************************************
@@ -3439,10 +3439,10 @@
 >a solution here?  Maybe it was discussed before. I recall we did once
 >consider using child packages as one of the options when discussing cyclic
 >packages.
->  
+>
 >
-I think we need a solution which is as simple as possible (but not 
-simpler).  Effectively splitting a package specification into two parts 
+I think we need a solution which is as simple as possible (but not
+simpler).  Effectively splitting a package specification into two parts
 is not really a solution, or if it is, there is no work to be done:
 
 package Private_Type is
@@ -3459,29 +3459,29 @@
 
 package To_Be_Withed renames Private_Type.Child:
 
-Three separate compliation units, plus one or two bodies, but it does 
-the trick.  If this solution is sufficient, fine.  If not, the need is 
-for a simpler solution not one that is more complex even if more 
+Three separate compliation units, plus one or two bodies, but it does
+the trick.  If this solution is sufficient, fine.  If not, the need is
+for a simpler solution not one that is more complex even if more
 general.  I think that limits the possibilities to three:
 
-1.  Change the rules so that a generic package declaration with a formal 
-parameter of a private type does not cause freezing of the private 
-type--but any use of the generic instance does.  Second, allow the 
-instantiation of the body of the generic package to be deferred until 
-some point in the private part.  (At the end is probably simplest. But 
-that forces any renamings of operations of the package to be done in the 
+1.  Change the rules so that a generic package declaration with a formal
+parameter of a private type does not cause freezing of the private
+type--but any use of the generic instance does.  Second, allow the
+instantiation of the body of the generic package to be deferred until
+some point in the private part.  (At the end is probably simplest. But
+that forces any renamings of operations of the package to be done in the
 body of the package.)
 
-This does lead to complexities for implementors and language lawyers, 
+This does lead to complexities for implementors and language lawyers,
 but ordinary users can just do what seems natural.
 
-2.  Have a new syntax which allows for two part instantiation of a 
-generic package.  This would seem to have all the complexities of the 
-above solution, and be less simple for users.  But it would mean no 
+2.  Have a new syntax which allows for two part instantiation of a
+generic package.  This would seem to have all the complexities of the
+above solution, and be less simple for users.  But it would mean no
 changes to existing legal programs.
 
-3. Allow end private, but only followed by generic instantiations (and 
-only one private part).  Again, renaming of operations gets pushed to 
+3. Allow end private, but only followed by generic instantiations (and
+only one private part).  Again, renaming of operations gets pushed to
 the package body.
 
 ****************************************************************
@@ -3489,19 +3489,19 @@
 From: Jean-Pierre Rosen
 Date: Friday, November 2, 2007  1:09 PM
 
-> I think we need a solution which is as simple as possible (but not 
-> simpler).  Effectively splitting a package specification into two parts 
+> I think we need a solution which is as simple as possible (but not
+> simpler).  Effectively splitting a package specification into two parts
 > is not really a solution, or if it is, there is no work to be done:
 
 Agreed
- 
+
 > package Private_Type is
 >    type PT is private;
 >    ...
 > private
 >    ...
 > end Private_Type;
-> 
+>
 > package Private_Type.Child is
 >   subtype SPT is PT;
 >   package Container is new ...
@@ -3509,13 +3509,13 @@
 
 Why not:
    package Private_Type.Container is new...
-> 
+>
 > package To_Be_Withed renames Private_Type.Child:
- 
+
 Why do we need this?
 
-If the only issue is that the user needs to "with" several children, we 
-may introduce a "with all Pack" clause that would "with" pack and all 
+If the only issue is that the user needs to "with" several children, we
+may introduce a "with all Pack" clause that would "with" pack and all
 children that are part of the environment.
 
 ****************************************************************
@@ -3712,7 +3712,7 @@
 From: Randy Brukardt
 Date: Thursday, July 31, 2008 11:22 PM
 
-> I recently took 4, 4-hour train rides, and here is one of the products 
+> I recently took 4, 4-hour train rides, and here is one of the products
 > of having a bit too much time on my hands (it doesn't happen often!).
 
 Please schedule some more train trips. Perhaps on the Trans-Siberian
@@ -3723,10 +3723,10 @@
 find them. That's Steve's job. ;-)
 
 The AI asks:
-> TBD: Is it OK to refer to the "first declaration list of the visible 
-> part of a package"?  Does that work for generic packages, or is the 
-> first declaration list the formal part?  Do we need to say "first list 
-> of basic_declarative_items of the visible part of the package"?  Same 
+> TBD: Is it OK to refer to the "first declaration list of the visible
+> part of a package"?  Does that work for generic packages, or is the
+> first declaration list the formal part?  Do we need to say "first list
+> of basic_declarative_items of the visible part of the package"?  Same
 > question applies for deferred constants in 7.4(3).
 
 "first list" and "third list" make me rather ill. I think that both of
@@ -3741,12 +3741,12 @@
 
 Under "IMPLEMENTATION ISSUES", there is:
 
-> Another possible approach might be to treat the private part roughly 
-> like a nested construct, where the visibility is "pushed" before the 
-> private part, and then "popped" afterward.  Prior to popping the 
-> private part visibility, it would want to be "saved" so that when it 
-> is wanted again, such as in the package body, or in the private part 
-> of some child, it can be restored.  This kind of "save" might be 
+> Another possible approach might be to treat the private part roughly
+> like a nested construct, where the visibility is "pushed" before the
+> private part, and then "popped" afterward.  Prior to popping the
+> private part visibility, it would want to be "saved" so that when it
+> is wanted again, such as in the package body, or in the private part
+> of some child, it can be restored.  This kind of "save" might be
 > similar to what is done with subunit "stubs."
 
 While I can't argue with the basic idea (it won't work in Janus/Ada,
@@ -3757,16 +3757,16 @@
 when processing the subunit.) That sort of approach would not work here,
 because it would drop the contents of the secondary visible part (ah, much
 better than "end private" part or "third declaration list"), which clearly
-wouldn't do. 
+wouldn't do.
 
 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 
+> 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
@@ -3805,17 +3805,17 @@
 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 
+>
+>> 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 
+>
+> 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
@@ -3844,31 +3844,31 @@
 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 
+>    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 
+>
+> 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 
+>
+> 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.
 
 
@@ -3882,13 +3882,13 @@
 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 
+> 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 
+>  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
@@ -3939,10 +3939,10 @@
 From: Tucker Taft
 Date: Friday, August 1, 2008  7:15 PM
 
-> The fact that the representation clause is visible affects 
+> 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 
+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.
@@ -3952,23 +3952,23 @@
 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 
+> 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 
+> 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 
+> 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
@@ -3977,7 +3977,7 @@
 >          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
@@ -3988,9 +3988,9 @@
 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 
+> 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
@@ -4003,7 +4003,7 @@
 From: Randy Brukardt
 Date: Friday, August 1, 2008  7:32 PM
 
-> Perhaps.  However, I had originally asked about leaving off the ";" on 
+> 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"... ;-).
 
@@ -4026,22 +4026,22 @@
          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 
+> 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 
+> > 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 
+>
+> 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
@@ -4055,8 +4055,8 @@
 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 
+> 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
@@ -4098,36 +4098,36 @@
 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 
+>
+> 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 
+
+> 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.
@@ -4137,7 +4137,7 @@
 From: John Barnes
 Date: Monday, August 4, 2008  1:40 AM
 
->> Perhaps.  However, I had originally asked about leaving off the ";" 
+>> Perhaps.  However, I had originally asked about leaving off the ";"
 >> on "end private;" and that made John ill.
 
 Yes it did.
@@ -4145,12 +4145,12 @@
 
 >> 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" 
+> 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 
+> "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.
@@ -4174,10 +4174,10 @@
 > >          type X is private;
 > >       end Abc;
 > >
-> > That is, can a private type declaration appear in the trailing 
+> > That is, can a private type declaration appear in the trailing
 > > visible part?
 >
-> No.  In the proposal as written, private types and deferred constants 
+> No.  In the proposal as written, private types and deferred constants
 > are only permitted in the pre-private visible part.
 
 OK, but why?
@@ -4213,48 +4213,48 @@
 From: Randy Brukardt
 Date: Monday, August 4, 2008  6:36 PM
 
-> > No.  In the proposal as written, private types and deferred 
+> > 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 
+> 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 
+> 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 
+
+> 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 
+
+> 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,
@@ -4262,7 +4262,7 @@
 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 
+> 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
@@ -4277,14 +4277,14 @@
 
 > > OK, but why?
 >
-> Because it would mean abandoning the linear elaboration/declaration 
+> Because it would mean abandoning the linear elaboration/declaration
 > model, perhaps?
 
-Are you saying that certain declarations would have to be elaborated 
+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 
+> 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
@@ -4298,36 +4298,36 @@
 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 
+> 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 
+> > 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 
+> 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 
+> 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 
+> > 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 
+> 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
@@ -4342,20 +4342,20 @@
 ...
 > > 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 
+>
+> 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 
+> > 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.
@@ -4366,17 +4366,17 @@
 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 
+> > 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 
+>
+> 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 
+> 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.
@@ -4523,15 +4523,15 @@
 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 
+> > > 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 
+> > 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 
+>
+> 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
@@ -4545,7 +4545,7 @@
 From: Edmond Schonberg
 Date: Tuesday, August 5, 2008  7:58 AM
 
-> > It might also facilitate the proposal to extract the private 
+> > 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
@@ -4666,19 +4666,19 @@
 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 
+> 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 
+> 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"
@@ -4691,7 +4691,7 @@
 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 
+> I find your suggestion confusing and inconsistent with other parts of
 > the language, ...
 
 Yes, it's certainly inconsistent with longstanding terminology such
@@ -4751,7 +4751,7 @@
 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 
+> 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
@@ -4828,10 +4828,10 @@
 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, 
+> 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.
@@ -4967,9 +4967,9 @@
 From: Dan Eilers
 Date: Friday, August 8, 2008  1:15 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 
+> 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.
@@ -5031,9 +5031,9 @@
 From: Robert Dewar
 Date: Friday, August 8, 2008  1:32 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 
+> 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.
 
@@ -5063,11 +5063,11 @@
 :-(
 
 > Elegance requires consistency with high-level language goals.
-> As you note, the purpose of a package spec is to define the visible 
-> part of an abstraction.  Any mixing of irrelevant private details 
-> within that spec is inelegant.  The current two-part solution is 
-> somewhat elegant in that it allows the reader to stop reading when 
-> they get to the private keyword, but the proposed three-part solution 
+> As you note, the purpose of a package spec is to define the visible
+> part of an abstraction.  Any mixing of irrelevant private details
+> within that spec is inelegant.  The current two-part solution is
+> somewhat elegant in that it allows the reader to stop reading when
+> they get to the private keyword, but the proposed three-part solution
 > loses that elegance.
 
 indeed, see above
@@ -5080,7 +5080,7 @@
 From: Randy Brukardt
 Date: Saturday, August 9, 2008  1:28 AM
 
-> Can't we find a more elegant solution here that does not destroy the 
+> Can't we find a more elegant solution here that does not destroy the
 > entire structure of private parts?
 
 Well, we've been trying for quite a while now, and we aren't any closer
@@ -5169,7 +5169,7 @@
 Date: Saturday, August 9, 2008  10:01 AM
 
 ...
-> This does not seem to apply in this case. Neither X is visible at the 
+> This does not seem to apply in this case. Neither X is visible at the
 > place of the declaration of the other.
 
 Clearly this must be illegal.  There are special words to make disallow
@@ -5180,27 +5180,27 @@
 I guess I had presumed there were already enough rules to ensure that,
 but as you point out, at least the one above doesn't quite accomplish
 the goal.
- 
-> There are similar questions about the overriding relationships between 
-> declarations in the private part and the post-private part of a 
+
+> There are similar questions about the overriding relationships between
+> declarations in the private part and the post-private part of a
 > package.
-> 
+>
 > Given
-> 
+>
 >   package Pkg2 is
 >     type Has_No_Foo is tagged null record;
 >     type Has_Foo is new Has_No_Foo with null record;
 >     procedure Foo (X : Has_Foo);
-> 
+>
 >     type Two_Part is new Has_No_Foo with private;
 >   private
 >     type Two_Part is new Has_Foo with null record;
 >   end private
 >     procedure Foo (X : Two_Part);
 >   end Pkg2;
-> 
-> does the (second) explicit declaration of Foo override the implicit 
-> declaration of Foo that occurs at the point of the completion of the 
+>
+> does the (second) explicit declaration of Foo override the implicit
+> declaration of Foo that occurs at the point of the completion of the
 > type Two_Part?
 
 Explicit declarations always override inherited subprograms, no matter
@@ -5213,9 +5213,9 @@
 From: Randy Brukardt
 Date: Saturday, August 9, 2008  7:31 PM
 
-> Explicit declarations always override inherited subprograms, no matter 
-> which one comes first.  I would expect the existing rules already 
-> cover this situation, though as in the case above, the existing rules 
+> Explicit declarations always override inherited subprograms, no matter
+> which one comes first.  I would expect the existing rules already
+> cover this situation, though as in the case above, the existing rules
 > might need more tweaking.
 
 It took me a while to figure this out from the wording, but I think
@@ -5233,11 +5233,11 @@
 Date: Monday, August 11, 2008  11:49 AM
 
 ...
->> does the (second) explicit declaration of Foo override the implicit 
->> declaration of Foo that occurs at the point of the completion of the 
+>> does the (second) explicit declaration of Foo override the implicit
+>> declaration of Foo that occurs at the point of the completion of the
 >> type Two_Part?
 
-> Explicit declarations always override inherited subprograms, no matter 
+> Explicit declarations always override inherited subprograms, no matter
 > which one comes first.
 
 I agree with you, but overriding something that you aren't allowed to see
@@ -5273,20 +5273,20 @@
 Date: Tuesday, August 12, 2008  5:49 AM
 
 ...
-> I agree with you, but overriding something that you aren't allowed to 
+> I agree with you, but overriding something that you aren't allowed to
 > see seems odd.
 
 The overriding is only relevant at a place where both are visible, so
 I don't see that there is an anomaly.
- 
-> This becomes clearer if we add an overriding indicator to the final 
+
+> This becomes clearer if we add an overriding indicator to the final
 > explicit declaration of Foo:
-> 
+>
 >    overriding procedure Foo (X : Two_Part);
-> 
-> Now the legality of this declaration depends on the contents of a 
+>
+> Now the legality of this declaration depends on the contents of a
 > private part that it is not supposed to be able to see into.
-> This is not unprecedented (rep clause checking, detection of recursive 
+> This is not unprecedented (rep clause checking, detection of recursive
 > types), but it is not the sort of thing we want to encourage.
 
 Isn't this more similar to the case where you have a private extension,
@@ -5298,25 +5298,25 @@
 permitted.  However, similarly, "not overriding"
 would not be permitted, because eventually the declaration
 *is* overriding (in the body).
- 
-> I suppose you could tweak the rules for overriding indicators to 
-> somehow disallow the indicator in this case (while continuing to 
+
+> I suppose you could tweak the rules for overriding indicators to
+> somehow disallow the indicator in this case (while continuing to
 > disallow a "not overriding" indicator).
 
 I don't see the "tweak" needed, presuming it doesn't override until
 you get to a point where they both are visible.
- 
-> On the other hand, one could argue that we aren't really doing serious 
-> damage to the privacy model here because this is all within one 
+
+> On the other hand, one could argue that we aren't really doing serious
+> damage to the privacy model here because this is all within one
 > package spec.
-> 
+>
 > What do you think?
 
 I don't think the overriding would be relevant until the body, which
 is why neither "overriding" nor "not overriding" would be legal.
 
-> I realize that this may be a case of prematurely diving into the 
-> low-level details, but I think it is useful to point out that this 
+> I realize that this may be a case of prematurely diving into the
+> low-level details, but I think it is useful to point out that this
 > proposal may turn out to be more complicated than it seems at first.
 
 This one doesn't seem to be a problem to me, based on the current wording.
@@ -5346,15 +5346,15 @@
 From: Robert A. Duff
 Date: Tuesday, August 12, 2008  11:21 AM
 
-> I agree with you, but overriding something that you aren't allowed to 
+> I agree with you, but overriding something that you aren't allowed to
 > see seems odd.
-> 
-> This becomes clearer if we add an overriding indicator to the final 
+>
+> This becomes clearer if we add an overriding indicator to the final
 > explicit declaration of Foo:
-> 
+>
 >    overriding procedure Foo (X : Two_Part);
-> 
-> Now the legality of this declaration depends on the contents of a 
+>
+> Now the legality of this declaration depends on the contents of a
 > private part that it is not supposed to be able to see into.
 
 I think privacy breakage within a single package is not really privacy
@@ -5380,18 +5380,18 @@
    end Pkg2;
 
 Steve said:
-> I suppose you could tweak the rules for overriding indicators to 
-> somehow disallow the indicator in this case (while continuing to 
+> I suppose you could tweak the rules for overriding indicators to
+> somehow disallow the indicator in this case (while continuing to
 > disallow a "not overriding" indicator).
 
 Tuck said:
-> I don't see the "tweak" needed, presuming it doesn't override until 
+> I don't see the "tweak" needed, presuming it doesn't override until
 > you get to a point where they both are visible.
 
 8.3.1(5/2) says
    "If ..., then the operation shall override a homograph at
     the place of the declaration ..."
- 
+
 Section 8.3 gives clear rules about whether a given declaration overrides
 another declaration, but it is less clear in defining the point at
 which the overriding occurs. One definition would be "at the second
@@ -5409,10 +5409,10 @@
 Date: Tuesday, August 12, 2008  11:35 AM
 
 > 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 
+> *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.
 
@@ -5463,7 +5463,7 @@
 From: Randy Brukardt
 Date: Wednesday, August 13, 2008  2:13 PM
 
-Bob Duff writes: 
+Bob Duff writes:
 
 ...
 Seems like all goodness here. What's the catch? There must be one,
@@ -5500,7 +5500,7 @@
 these ideas are relevant to Ada.  Maybe later, especially if you
 goad me some more...  ;-)
 
-> One obvious question, given the example above, when does the 
+> One obvious question, given the example above, when does the
 > elaboration (initialization if you prefer) of Zero occur?
 
 All elaboration happens in the body.  Specs are not elaborated.  Specs
@@ -5534,16 +5534,16 @@
 
 >... How do you prevent dependence
 > on uninitialized things (that is, things that were not elaborated yet)?
-> (Imagine that Value depends on a local object to the body of Big_Nums,  
+> (Imagine that Value depends on a local object to the body of Big_Nums,
 >perhaps a performance counter.)
 
 The body-decl of Zero must occur after the body-decl of Value, which must
 occur after the local object you mentioned.
 These things are elaborated (only in the body!) in that order.
 
-> It's well known that the run-time elaboration checks of Ada aren't 
-> really needed (if you are willing to take a few more restrictions), 
-> but it isn't at all obvious how to avoid the other limitations of the 
+> It's well known that the run-time elaboration checks of Ada aren't
+> really needed (if you are willing to take a few more restrictions),
+> but it isn't at all obvious how to avoid the other limitations of the
 > linear elaboration model without adding erroneousness.
 
 ****************************************************************
@@ -5560,9 +5560,9 @@
 From: Robert A. Duff
 Date: Wednesday, August 13, 2008  11:21 PM
 
-> One of the "details" I didn't mention is that everything exported has 
-> to have two decls -- one in the spec, one in the body.  Most things 
-> work this way in Ada (since most exported things are subprograms).  In 
+> One of the "details" I didn't mention is that everything exported has
+> to have two decls -- one in the spec, one in the body.  Most things
+> work this way in Ada (since most exported things are subprograms).  In
 > my language, you have:
 ...
 
@@ -5661,7 +5661,7 @@
 From: Robert A. Duff
 Date: Tuesday, August 12, 2008  11:17 AM
 
-The difference is in the client view.  In the first example, the 
+The difference is in the client view.  In the first example, the
 client has to say both "with Abc" and "with Abc.Inner", and then
 either "Abc.Inner.Whatever", or "use Abc.Inner".  The second example
 makes it as if the stuff in the inner package is declared immediately
@@ -5681,8 +5681,8 @@
 From: Jean-Pierre Rosen
 Date: Monday, August 11, 2008  3:06 AM
 
-> Well I can't see that the second example here is enough of a gain on 
-> the first one to justify adding this mechanism, what's the big deal in 
+> Well I can't see that the second example here is enough of a gain on
+> the first one to justify adding this mechanism, what's the big deal in
 > choosing a name (almost always useful anyway) and adding a use clause?
 
 Actually, I think one of the early proposals was to define a package
@@ -5723,11 +5723,13 @@
 From: Randy Brukardt
 Date: Wednesday, August 13, 2008  3:17 PM
 
-> Yes, sure, but is there an example that cannot be solved with nested 
-> packages? If not, it turns the issue from "impossibility" to 
+> Yes, sure, but is there an example that cannot be solved with nested
+> packages? If not, it turns the issue from "impossibility" to
 > "inconvenience".
 
-There are such examples, because nested packages don't allow the declaration of primitive operations of the outer type. But "public" doesn't work for that, either.
+There are such examples, because nested packages don't allow the declaration of
+primitive operations of the outer type. But "public" doesn't work for that,
+either.
 
 Consider an example like (based on a Claw abstraction):
 
@@ -5747,9 +5749,12 @@
         type Menu_Item_Type is ...;
     end Menus;
 
-Make_Submenu and Get_Submenu are primitive, dispatching operations of Menu_Item_Type.
+Make_Submenu and Get_Submenu are primitive, dispatching operations of
+Menu_Item_Type.
 
-Now, imagine that you want to have a version of Make_Submenu for vectors of menu items. (This seems a very reasonable thing to want to do, especially given the difficulty of handling arrays with unknown bounds.)
+Now, imagine that you want to have a version of Make_Submenu for vectors of menu
+items. (This seems a very reasonable thing to want to do, especially given the
+difficulty of handling arrays with unknown bounds.)
 
 The basic conversion would look like:
 
@@ -5771,7 +5776,11 @@
         type Menu_Item_Type is ...;
     end Menus;
 
-but as noted, this is illegal because Menu_Item_Type is not completed at the point of the instantiation (and thus freezing it is illegal). [I added the 'Class because a Vector is a tagged type, and non-primitive parameters of a tagged specific type are du
bious: they would not work with extensions and that defeats the purpose of taggedness.]
+but as noted, this is illegal because Menu_Item_Type is not completed at the
+point of the instantiation (and thus freezing it is illegal). [I added the
+'Class because a Vector is a tagged type, and non-primitive parameters of a
+tagged specific type are dubious: they would not work with extensions and that
+defeats the purpose of taggedness.]
 
 Trying Tucker's proposal:
 
@@ -5794,14 +5803,20 @@
         -- Many other operations here.
     end Menus;
 
-but now the primitive operations are illegal because you can't declare primitive operations for a type (Menu_Item_Type) after the type is frozen.
+but now the primitive operations are illegal because you can't declare primitive
+operations for a type (Menu_Item_Type) after the type is frozen.
 
-Tucker had proposed using renames-as-body to get around that, but that doesn't work here because we donít have visibility on the type Menu_Vector.Vector before the instance.
+Tucker had proposed using renames-as-body to get around that, but that doesn't
+work here because we donít have visibility on the type Menu_Vector.Vector before
+the instance.
 
 There is also a complication if Menu_Item_Type needs an
-access-to-Menu_Item_Vector: you'd need to use a Taft-incomplete type in the private part which would be completed in the body (probably with a subtype).
+access-to-Menu_Item_Vector: you'd need to use a Taft-incomplete type in the
+private part which would be completed in the body (probably with a subtype).
 
-A named nested package doesn't work either: (I'm using a named one here so it is clear what is going on, but the extension to Jean-Pierre's proposal should be obvious.)
+A named nested package doesn't work either: (I'm using a named one here so it is
+clear what is going on, but the extension to Jean-Pierre's proposal should be
+obvious.)
 
     with Ada.Containers.Vectors;
     package Menus is
@@ -5822,7 +5837,9 @@
 
     end Menus;
 
-This works, but the routines Make_Submenu and Get_Submenu are no longer primitive. If you need them for dispatching purposes, you are sunk. Again, you also need a Taft-incomplete type in the private part.
+This works, but the routines Make_Submenu and Get_Submenu are no longer
+primitive. If you need them for dispatching purposes, you are sunk. Again, you
+also need a Taft-incomplete type in the private part.
 
 At one point, Tucker had suggested making this Vector type private to get it
 exported:
@@ -5846,10 +5863,14 @@
         type Menu_Vector_Type is new Menu_Vector.Vector with null record;
     end Menus;
 
-[The 'Class is required here, else we'd have a primitive of two tagged types at once.] Now we have a legal spec., but we no longer have a visible vector type, so we'd have to manually export all of the vector operations. This does get rid of the Taft-inco
mplete type, so it is not all bad.
+[The 'Class is required here, else we'd have a primitive of two tagged types at
+once.] Now we have a legal spec., but we no longer have a visible vector type,
+so we'd have to manually export all of the vector operations. This does get rid
+of the Taft-incomplete type, so it is not all bad.
 
 I can't think of any way to make this work with the rules Tucker proposed.
-However, we could make it work if we allowed a private type to be completed in the *second* visible part:
+However, we could make it work if we allowed a private type to be completed in
+the *second* visible part:
 
     with Ada.Containers.Vectors;
     package Menus is
@@ -5871,7 +5892,9 @@
         type Menu_Vector_Type is new Menu_Vector.Vector with null record;
     end Menus;
 
-Now we do have the right visibility on Menu_Vector_Type to know that it is a Vector. As an added bonus, the vector operations are inherited here, so they have the same visibility as the type Menu_Vector_Type.
+Now we do have the right visibility on Menu_Vector_Type to know that it is a
+Vector. As an added bonus, the vector operations are inherited here, so they
+have the same visibility as the type Menu_Vector_Type.
 
 This problem *can* be solved with my limited instance proposal (see
 AI05-0074-1):
@@ -5880,7 +5903,7 @@
     package Menus is
         type Menu_Item_Type is tagged private;
         package Menu_Vector is limited new Ada.Containers.Vectors
-(Menu_Item_Type);	
+(Menu_Item_Type);
 
         procedure Make_Submenu (Menu_Item : in out Menu_Item_Type;
                                 New_Submenu : in Menu_Vector.Vector'Class);
@@ -5895,28 +5918,36 @@
         package Menu_Vector is new Ada.Containers.Vectors (Menu_Item_Type);
     end Menus;
 
-But note that we had to change Get_Submenu to a procedure in order to do it (parameters of tagged limited types are allowed, return values of them are not allowed). As an added bonus, no Taft-incomplete type is needed in the private part, as the instantia
tion provides the needed limited view.
+But note that we had to change Get_Submenu to a procedure in order to do it
+(parameters of tagged limited types are allowed, return values of them are not
+allowed). As an added bonus, no Taft-incomplete type is needed in the private
+part, as the instantiation provides the needed limited view.
+
+But I'm not pushing very hard for this solution, because the client view of the
+"limited" instance is *not* limited, and that's pretty weird (even though it
+works fine semantically). I haven't been able to think of syntax that makes that
+dichotomy clear, and I think it needs to be fairly clear.
+
+The question has to be whether this (and similar corner cases) are important
+enough to make a solution for. Most of the examples can be solved with nested or
+child packages; while that is not ideal, it may be enough.
 
-But I'm not pushing very hard for this solution, because the client view of the "limited" instance is *not* limited, and that's pretty weird (even though it works fine semantically). I haven't been able to think of syntax that makes that dichotomy clear, 
and I think it needs to be fairly clear.
-
-The question has to be whether this (and similar corner cases) are important enough to make a solution for. Most of the examples can be solved with nested or child packages; while that is not ideal, it may be enough.
-
 ****************************************************************
 
 From: Robert A. Duff
 Date: Wednesday, August 13, 2008  4:57 PM
 
-> Now, imagine that you want to have a version of Make_Submenu for 
-> vectors of menu items. (This seems a very reasonable thing to want to 
-> do, especially given the difficulty of handling arrays with unknown 
+> Now, imagine that you want to have a version of Make_Submenu for
+> vectors of menu items. (This seems a very reasonable thing to want to
+> do, especially given the difficulty of handling arrays with unknown
 > bounds.)
 
 Very reasonable indeed.  I'd say that vectors should behave _exactly_
 like arrays, except that vectors are growable.  We're pretty far from that
 goal, though.
 
-> [The 'Class is required here, else we'd have a primitive of two tagged 
-> types at once.] Now we have a legal spec., but we no longer have a 
+> [The 'Class is required here, else we'd have a primitive of two tagged
+> types at once.] Now we have a legal spec., but we no longer have a
 > visible vector type, so we'd have to manually export all of the vector operations.
 
 So what do you think of the idea I mentioned yesterday -- a syntactic
@@ -5928,12 +5959,12 @@
 Date: Wednesday, August 13, 2008  7:08 PM
 
 ...
-> > Now, imagine that you want to have a version of Make_Submenu for 
-> > vectors of menu items. (This seems a very reasonable thing to want 
-> > to do, especially given the difficulty of handling arrays with 
+> > Now, imagine that you want to have a version of Make_Submenu for
+> > vectors of menu items. (This seems a very reasonable thing to want
+> > to do, especially given the difficulty of handling arrays with
 > > unknown bounds.)
-> 
-> Very reasonable indeed.  I'd say that vectors should behave _exactly_ 
+>
+> Very reasonable indeed.  I'd say that vectors should behave _exactly_
 > like arrays, except that vectors are growable.
 > We're pretty far from that goal, though.
 
@@ -5942,13 +5973,13 @@
 they can be done cheaply enough. (Note that we sort of have user-defined
 selection via the prefixed view mechanism.)
 
-> > [The 'Class is required here, else we'd have a primitive of two 
-> > tagged types at once.] Now we have a legal spec., but we no longer 
+> > [The 'Class is required here, else we'd have a primitive of two
+> > tagged types at once.] Now we have a legal spec., but we no longer
 > > have a visible vector type, so we'd have to manually export all of
 > the vector operations.
-> 
-> So what do you think of the idea I mentioned yesterday -- a syntactic 
-> shorthand that means "rename all the stuff from one place into 
+>
+> So what do you think of the idea I mentioned yesterday -- a syntactic
+> shorthand that means "rename all the stuff from one place into
 > another".
 
 I don't think that would help this particular example; as I noted in
@@ -5974,14 +6005,14 @@
 Date: Wednesday, August 13, 2008  7:37 PM
 
 ...
-> Yes, sure, but is there an example that cannot be solved with nested 
-> packages? If not, it turns the issue from "impossibility" to 
+> Yes, sure, but is there an example that cannot be solved with nested
+> packages? If not, it turns the issue from "impossibility" to
 > "inconvenience".
-> 
-> BTW, my proposal is not that different. If you read "package is" as 
-> "public", "private" as "private" :-) and "end" as "end private", it is 
-> pretty much equivalent to Tuck's proposal. But the idea is that by 
-> basing it on an existing notion, it would make it easier to answer 
+>
+> BTW, my proposal is not that different. If you read "package is" as
+> "public", "private" as "private" :-) and "end" as "end private", it is
+> pretty much equivalent to Tuck's proposal. But the idea is that by
+> basing it on an existing notion, it would make it easier to answer
 > many questions simply by saying: "just as for a regular subpackage".
 
 
@@ -5997,7 +6028,7 @@
 From: Edmond Schonberg
 Date: Thursday, August 14, 2008  7:47 AM
 
-> But I don't want to rule any idea out-of-hand, as nothing has worked 
+> But I don't want to rule any idea out-of-hand, as nothing has worked
 > that well so far...
 
 Indeed, and I would like to put back on the table a suggestion we discarded
@@ -6006,7 +6037,7 @@
 It is simply to say that an instantiation does not freeze the actuals: they
 become frozen in the normal course of things AFTER the instantiation. I
 realize that Pascal was vociferously opposed to this, and so was I, because
-freezing rules are an extremely delicate part of each implementation.  
+freezing rules are an extremely delicate part of each implementation.
 However, all the proposals so far propose a complex mechanism that will be
 hard to graft onto existing implementations, complex to explain, and contribute
 to the general complexity of the language for a very small gain.  By contrast,
@@ -6038,23 +6069,23 @@
 From: Edmond Schonberg
 Date: Thursday, August 14, 2008  11:34 AM
 
-> A related proposal was also discarded on the grounds that it would 
-> involve changes to the freezing rules. We had discussed the idea of 
-> providing a mechanism to somehow defer the elaboration of a package 
-> instance body so that it did not occur directly after the elaboration 
-> of the instance spec. This change in the dynamic semantics would be 
-> accompanied by a change in the freezing rules so that the freezing 
-> associated with an instance spec would be performed as for an ordinary 
-> package spec and the wholesale freezing associated with the instance 
-> body would be performed at the point where the instance body is 
+> A related proposal was also discarded on the grounds that it would
+> involve changes to the freezing rules. We had discussed the idea of
+> providing a mechanism to somehow defer the elaboration of a package
+> instance body so that it did not occur directly after the elaboration
+> of the instance spec. This change in the dynamic semantics would be
+> accompanied by a change in the freezing rules so that the freezing
+> associated with an instance spec would be performed as for an ordinary
+> package spec and the wholesale freezing associated with the instance
+> body would be performed at the point where the instance body is
 > elaborated.
 
 Was this just a change in the freezing rules, or did it involve some syntax?
 I don't recall.  Changing the rules so that the instance spec is treated
 like any local package is what I have in mind to experiment with.
 
-> If we are willing to consider changes to the freezing rules, then we 
-> might want to reconsider this approach (which, incidentally, handles 
+> If we are willing to consider changes to the freezing rules, then we
+> might want to reconsider this approach (which, incidentally, handles
 > the case of a generic body which declares an object of a formal type).
 
 I trust that the Baird's "here be dragons" examples are to follow shortly...
@@ -6064,8 +6095,8 @@
 From: Robert Dewar
 Date: Thursday, August 14, 2008  11:46 AM
 
-> If we are willing to consider changes to the freezing rules, then we 
-> might want to reconsider this approach (which, incidentally, handles 
+> If we are willing to consider changes to the freezing rules, then we
+> might want to reconsider this approach (which, incidentally, handles
 > the case of a generic body which declares an object of a formal type).
 
 I really find approaches based on changing the freezing rules to be far
@@ -6076,7 +6107,7 @@
 From: Steve Baird
 Date: Thursday, August 14, 2008  1:46 PM
 
-> Was this just a change in the freezing rules, or did it involve some 
+> Was this just a change in the freezing rules, or did it involve some
 > syntax? I don't recall.
 
 I don't think we got that far.
@@ -6111,9 +6142,9 @@
 specifying or confirming (like overriding_indicators) that the elaboration
 of a given instance body is or is not deferred.
 
-> I trust that the Baird's "here be dragons" examples are to follow 
+> I trust that the Baird's "here be dragons" examples are to follow
 > shortly...
-> 
+>
 
 I actually like this general approach. Any change in the point at which
 a body is elaborated would require a corresponding change in the point
@@ -6126,12 +6157,12 @@
 From: Robert A. Duff
 Date: Thursday, August 14, 2008  2:11 PM
 
-> The thing I don't like about this approach is that a minor change 
-> whose significance is difficult to appreciate without an understanding 
-> of the freezing rules could change the point at which an instance body 
+> The thing I don't like about this approach is that a minor change
+> whose significance is difficult to appreciate without an understanding
+> of the freezing rules could change the point at which an instance body
 > is elaborated. I suspect that users (e.g., me) would find this confusing.
-> If it seemed important enough, we could introduce some mechanism for 
-> either specifying or confirming (like overriding_indicators) that the 
+> If it seemed important enough, we could introduce some mechanism for
+> either specifying or confirming (like overriding_indicators) that the
 > elaboration of a given instance body is or is not deferred.
 
 It seems unlikely that anybody cares when their instance bodies get elaborated.
@@ -6144,22 +6175,22 @@
 From: Randy Brukardt
 Date: Thursday, August 14, 2008  2:12 PM
 
-> Indeed, and I would like to put back on the table a suggestion we 
-> discarded months ago, but which now seems like a much smaller change 
-> to the description of the language (even though it might be an 
-> implementation earthquake).  It is simply to say that an instantiation 
+> Indeed, and I would like to put back on the table a suggestion we
+> discarded months ago, but which now seems like a much smaller change
+> to the description of the language (even though it might be an
+> implementation earthquake).  It is simply to say that an instantiation
 > does not freeze the
-> actuals: they become frozen in the  
-> normal course of things AFTER the instantiation.   I realize that  
-> Pascal was vociferously opposed to this, and so was I, because 
+> actuals: they become frozen in the
+> normal course of things AFTER the instantiation.   I realize that
+> Pascal was vociferously opposed to this, and so was I, because
 > freezing rules are an extremely delicate part of each implementation.
-> However, all the proposals so far propose a complex mechanism that 
-> will be hard to graft onto existing implementations, complex to 
-> explain, and contribute to the general complexity of the language for 
+> However, all the proposals so far propose a complex mechanism that
+> will be hard to graft onto existing implementations, complex to
+> explain, and contribute to the general complexity of the language for
 > a very small gain.  By contrast, removing
-> 13.14 (5) is almost invisible (except for implementors!).  
-> I'd be willing to experiment with this is GNAT, but of course other 
-> implementors would have to do the same for the experiment to be 
+> 13.14 (5) is almost invisible (except for implementors!).
+> I'd be willing to experiment with this is GNAT, but of course other
+> implementors would have to do the same for the experiment to be
 > convincing.
 
 Apparently, I lied, because I *do* reject this idea out of hand. That's
@@ -6200,9 +6231,9 @@
 Date: Thursday, August 14, 2008  2:53 PM
 
 > It seems unlikely that anybody cares when their instance bodies get elaborated.
-> Elab code normally initializes the thing itself, and doesn't reach out 
+> Elab code normally initializes the thing itself, and doesn't reach out
 > and cause "interesting" side effects that matter to other parts of the program.
-> So I can't get too excited about this issue -- even if it's not 
+> So I can't get too excited about this issue -- even if it's not
 > strictly compatible.
 
 I agree, in fact the sense of strong orderinng here is a language artifact,
@@ -6213,7 +6244,7 @@
 From: Randy Brukardt
 Date: Thursday, August 14, 2008  3:22 PM
 
-> So I can't get too excited about this issue -- even if it's not 
+> So I can't get too excited about this issue -- even if it's not
 > strictly compatible.
 
 I strongly disagree. I outlined some of the reasons in my last message, but
@@ -6221,7 +6252,7 @@
 Currently, there aren't any for access to things in an instance. For
 example:
 
-    package P is 
+    package P is
        Value : constant Boolean;
        package Inst is new Gen ...;
     private
@@ -6256,12 +6287,12 @@
 From: Robert Dewar
 Date: Thursday, August 14, 2008  3:29 PM
 
-> If we allow the body to elaboarate separately, we'll need to add 
-> access-before-elab checks to all of the contents of the generic body 
-> (and for Janus/Ada, given the code sharing, that would have a 
-> performance impact on *all* generics, whether they are instantiated 
-> this way or not). Moreover, this call could raise Program_Error 
-> because the body is not yet elaborated (that of course depends on the 
+> If we allow the body to elaboarate separately, we'll need to add
+> access-before-elab checks to all of the contents of the generic body
+> (and for Janus/Ada, given the code sharing, that would have a
+> performance impact on *all* generics, whether they are instantiated
+> this way or not). Moreover, this call could raise Program_Error
+> because the body is not yet elaborated (that of course depends on the
 > exact rule chosen). That seems like a serious incompatibly.
 
 That's certainly a point, although I think the time has come to stop the
@@ -6273,8 +6304,8 @@
 From: Randy Brukardt
 Date: Thursday, August 14, 2008  3:52 PM
 
-> That's certainly a point, although I think the time has come to stop 
-> the ceremonial worrying about impact on shared generics. However, in 
+> That's certainly a point, although I think the time has come to stop
+> the ceremonial worrying about impact on shared generics. However, in
 > the big shceme of things I think this would be tolerable.
 
 Nothing "ceremonial" about it, unless you are planning to offer me a job.
@@ -6308,7 +6339,7 @@
 From: Steve Baird
 Date: Thursday, August 14, 2008  3:30 PM
 
-> It seems unlikely that anybody cares when their instance bodies get 
+> It seems unlikely that anybody cares when their instance bodies get
 > elaborated.
 
 If I started with this unit
@@ -6400,7 +6431,7 @@
 Date: Thursday, August 14, 2008  5:35 PM
 
 > and decided to make T private (while still exporting the instance)
-> 
+>
 >    with G;
 >    pragma Elaborate_All (G);
 >    package Foo is
@@ -6410,8 +6441,8 @@
 >    private
 >       type T is range 1 .. 10;
 >    end Foo;
-> 
-> then I think I would care if the call to I.Some_Function failed its 
+>
+> then I think I would care if the call to I.Some_Function failed its
 > elaboration check and propagated Program_Error.
 
 But that's currently illegal.  I can't get excited if it fails at elab time
@@ -6422,28 +6453,28 @@
 From: Robert A. Duff
 Date: Thursday, August 14, 2008  5:40 PM
 
-> I strongly disagree. I outlined some of the reasons in my last 
-> message, but the most important one from a compatibility reason is 
-> access-before-elab checks. Currently, there aren't any for access to 
+> I strongly disagree. I outlined some of the reasons in my last
+> message, but the most important one from a compatibility reason is
+> access-before-elab checks. Currently, there aren't any for access to
 > things in an instance. For
 > example:
 
 I suppose I should take your advice to read all the old AIs and minutes
 before commenting further on this...
 
->     package P is 
+>     package P is
 >        Value : constant Boolean;
 >        package Inst is new Gen ...;
 >     private
 >        Value : constant Boolean := Inst.Is_Valid ...;
 >     end P;
-> 
-> The call into Inst is always OK in Ada as it stands; it can't raise 
+>
+> The call into Inst is always OK in Ada as it stands; it can't raise
 > Program_Error.
-> 
-> If we allow the body to elaboarate separately, we'll need to add 
-> access-before-elab checks to all of the contents of the generic body 
-> (and for Janus/Ada, given the code sharing, that would have a 
+>
+> If we allow the body to elaboarate separately, we'll need to add
+> access-before-elab checks to all of the contents of the generic body
+> (and for Janus/Ada, given the code sharing, that would have a
 > performance impact on *all* generics, whether they are instantiated this way or not).
 
 Just one meta-comment: I am in favor of the language design goal "shared
@@ -6456,11 +6487,11 @@
 From: Randy Brukardt
 Date: Thursday, August 14, 2008  6:06 PM
 
-> Just one meta-comment: I am in favor of the language design goal 
+> Just one meta-comment: I am in favor of the language design goal
 > "shared generic bodies (always-share, or
 > sometimes-share) should be feasible".
-> But I don't think it's possible to make the always-share model 
-> efficient, so I think we should tolerate inefficiencies there, within 
+> But I don't think it's possible to make the always-share model
+> efficient, so I think we should tolerate inefficiencies there, within
 > reason.
 
 This echoes what Robert said, and I can't argue with that sentiment. What
@@ -6484,14 +6515,14 @@
 From: Robert Dewar
 Date: Thursday, August 14, 2008  6:13 PM
 
-> This echoes what Robert said, and I can't argue with that sentiment. 
-> What bothers me here is less the inefficiency itself than the fact 
+> This echoes what Robert said, and I can't argue with that sentiment.
+> What bothers me here is less the inefficiency itself than the fact
 > that this will cause *existing* code that does *not* use this feature
 > to be less efficient.
-> Since Janus/Ada does elaboration checks inside of the called 
-> subprogram, it can't be removed unless the call is inlined or the 
-> check is known to never fail (as with some categorizations). This 
-> isn't a huge issue, because the added inefficiency is relatively 
+> Since Janus/Ada does elaboration checks inside of the called
+> subprogram, it can't be removed unless the call is inlined or the
+> check is known to never fail (as with some categorizations). This
+> isn't a huge issue, because the added inefficiency is relatively
 > small, but it is another downside to this proposal.
 
 Right, but static analysis could remove many of these elaboration checks,
@@ -6506,7 +6537,7 @@
 From: Steve Baird
 Date: Thursday, August 14, 2008  6:30 PM
 
-> But that's currently illegal.  I can't get excited if it fails at elab 
+> But that's currently illegal.  I can't get excited if it fails at elab
 > time instead.
 
 I think you would agree that making an apparently innocuous transformation
@@ -6529,7 +6560,7 @@
 From: Robert Dewar
 Date: Thursday, August 14, 2008  6:35 PM
 
-> In the case of this particular example, I think this would be a change 
+> In the case of this particular example, I think this would be a change
 > for the worse.
 
 Yes, but is this a typical example? or a cooked up one?
@@ -6554,11 +6585,11 @@
 From: Robert A. Duff
 Date: Friday, August 15, 2008  7:11 AM
 
-> > But that's currently illegal.  I can't get excited if it fails at 
+> > But that's currently illegal.  I can't get excited if it fails at
 > > elab time instead.
-> 
-> I think you would agree that making an apparently innocuous 
-> transformation and then discovering that your program is illegal is 
+>
+> I think you would agree that making an apparently innocuous
+> transformation and then discovering that your program is illegal is
 > preferable to inadvertently introducing a mysterious runtime error.
 
 Normally, I would, but in my book, elab failures are not "real" run-time
@@ -6570,9 +6601,9 @@
 but that's a different complaint, and is irrelevant here.
 
 >... If we modify the
-> previous example by replacing the call "I.Some_Function" with  
->"Almost_Always_True_But_Not_Quite_Always or else I.Some_Function", then  
->we get a package spec which *usually* elaborates successfully but  will 
+> previous example by replacing the call "I.Some_Function" with
+>"Almost_Always_True_But_Not_Quite_Always or else I.Some_Function", then
+>we get a package spec which *usually* elaborates successfully but  will
 >fail occasionally.
 
 Almost_Always_True_But_Not_Quite_Always must do some input (Text_IO.Get_Line,
@@ -6585,10 +6616,10 @@
 From: Robert Dewar
 Date: Friday, August 15, 2008  7:16 AM
 
-> Normally, I would, but in my book, elab failures are not "real" 
+> Normally, I would, but in my book, elab failures are not "real"
 > run-time errors
-> -- they are essentially equivalent to link-time errors, because unless 
-> you do something strange, they happen every time.  Even the most 
+> -- they are essentially equivalent to link-time errors, because unless
+> you do something strange, they happen every time.  Even the most
 > minimal regression test suite will catch them.
 
 It's not *so* strange to have elaboration code in a package body that
@@ -6620,23 +6651,23 @@
 From: Robert Dewar
 Date: Friday, August 15, 2008  9:52 AM
 
-> I gave up on this approach both because others find it distasteful 
-> (e.g. Pascal), but also because it wasn't obvious that it really 
-> solved the interesting problems.  Randy pointed out that there would 
-> be various restrictions on what you could do in the generic, and 
+> I gave up on this approach both because others find it distasteful
+> (e.g. Pascal), but also because it wasn't obvious that it really
+> solved the interesting problems.  Randy pointed out that there would
+> be various restrictions on what you could do in the generic, and
 > that's pretty annoying.
 
 Maybe it can't do everything, but it is SO much more palatable than the
 end private suggestion to me
- 
-> The post-private visible part seems very straightforward to me, since 
-> it mimics what things are like in the visible part of a child, and I 
-> know it accomplishes the goal of allowing essentially arbitrary 
-> instantiations of arbitrary generics inside the package spec where a 
-> private type is declared.  From my perspective, it only involves some 
-> relatively modest visibility fiddling.  It doesn't introduce any new 
-> overloading, freezing, elaboration, instantiation, or run-time 
-> semantics, all of which the partial instantiation process does, and 
+
+> The post-private visible part seems very straightforward to me, since
+> it mimics what things are like in the visible part of a child, and I
+> know it accomplishes the goal of allowing essentially arbitrary
+> instantiations of arbitrary generics inside the package spec where a
+> private type is declared.  From my perspective, it only involves some
+> relatively modest visibility fiddling.  It doesn't introduce any new
+> overloading, freezing, elaboration, instantiation, or run-time
+> semantics, all of which the partial instantiation process does, and
 > all of which are inordinately subtle in most compilers.
 
 repeating myself (in response to Tuck repeating himself :-))
@@ -6649,7 +6680,7 @@
 From: Robert A. Duff
 Date: Friday, August 15, 2008 10:09 AM
 
-> Normally, I would, but in my book, elab failures are not "real" 
+> Normally, I would, but in my book, elab failures are not "real"
 > run-time errors
 > -- they are essentially equivalent to link-time errors, ...
 
@@ -6707,27 +6738,27 @@
 From: Edmond Schonberg
 Date: Friday, August 15, 2008  1:41 PM
 
-> For the sake of compatibility, it would probably be a good idea to 
-> grant an implementation permission to perform the check at the point 
-> of the instance declaration in the case where the instance body is to 
+> For the sake of compatibility, it would probably be a good idea to
+> grant an implementation permission to perform the check at the point
+> of the instance declaration in the case where the instance body is to
 > be elaborated immediately after the instance spec.
 
 It is always permissible to freeze an entity at an earlier point if this
 can be done.  I would certainly check to see whether the actuals are
 already frozen before deciding to defer the elaboration of the instance body.
 
-> I bring this up now because the difference in generality between the 
-> two approaches (deferred instance body elaboration and post-private 
-> visible parts) is a significant issue. If a particular deferred 
-> instance proposal were unable to handle the preceding example, then 
-> that should be considered in evaluating the proposal. The relative 
-> complexity of the two proposals (both for users and for implementers) 
-> is also an issue and this question illustrates another (small) bit of 
+> I bring this up now because the difference in generality between the
+> two approaches (deferred instance body elaboration and post-private
+> visible parts) is a significant issue. If a particular deferred
+> instance proposal were unable to handle the preceding example, then
+> that should be considered in evaluating the proposal. The relative
+> complexity of the two proposals (both for users and for implementers)
+> is also an issue and this question illustrates another (small) bit of
 > complexity associated with the deferred instance approach.
 
 I don't see any problem with deferred freezing in this example, and I don't
-see any out-of-place elaboration checks. In the absence of any  
-reference to entities declared in I1 or I2, both packages are frozen   
+see any out-of-place elaboration checks. In the absence of any
+reference to entities declared in I1 or I2, both packages are frozen
 (and their bodies inserted) after the full declaration of T. If an entity
 from I2 is referenced,  given that the instantiation mentions
 G2 this freezes I1, which freezes T. If this happens before the full view
@@ -6738,7 +6769,7 @@
 From: Steve Baird
 Date: Friday, August 15, 2008  3:10 PM
 
-> I don't see any problem with deferred freezing in this example, and I 
+> I don't see any problem with deferred freezing in this example, and I
 > don't see any out-of-place elaboration checks.
 
 Applying 3.11(13) to this example, we get a runtime check at the point
@@ -6758,10 +6789,10 @@
 From: Edmond Schonberg
 Date: Friday, August 15, 2008  3:23 PM
 
-> Does this clarify things? I hope I'm not misunderstanding your point 
+> Does this clarify things? I hope I'm not misunderstanding your point
 > and then restating the obvious.
 
-Clearly as written this conflicts with the notion of delayed freezing. 
+Clearly as written this conflicts with the notion of delayed freezing.
 3.11 (13) would have to be modified to indicate that the check takes
 place at the point the instance is frozen, because that is where the
 generic body is needed. Given that it mentions freezing, the rule should
@@ -6772,15 +6803,15 @@
 From: Robert A. Duff
 Date: Friday, August 15, 2008  5:13 PM
 
-> Two proposals for dealing with this is written up in AI95-0359-1 and 
-> AI95-0359-2. (The file names are AI-00359.TXT and AI-10359.TXT, in 
+> Two proposals for dealing with this is written up in AI95-0359-1 and
+> AI95-0359-2. (The file names are AI-00359.TXT and AI-10359.TXT, in
 > case you've forgotten the weird encoding we used to use).
 
 There are actually four alternative versions of this AI.
 
 >...There's also a lot in
-> the minutes of the various meetings that discuss these proposals, and 
->in the  !appendix. I really don't want to have to go over all of this 
+> the minutes of the various meetings that discuss these proposals, and
+>in the  !appendix. I really don't want to have to go over all of this
 >same ground  again.
 
 Agreed.  We should all try to refrain from arguing before reading up on

Questions? Ask the ACAA Technical Agent