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

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

--- ai05s/ai05-0011-1.txt	2006/03/28 06:36:43	1.1
+++ ai05s/ai05-0011-1.txt	2006/04/01 06:59:17	1.2
@@ -2087,3 +2087,759 @@
 
 ****************************************************************
 
+From: Robert I. Eachus
+Date: Tuesday, March 28, 2006  1:21 AM
+
+>Good ideas, and they make "growable arrays" less painful.  But I don't think
+>they solve the general problem.
+
+Agreed.  But if there is currently a workable, but painful solution that 
+always works, which seems to be the case here, a 80% or 90% solution 
+that makes many common cases less painful is worth considering--as long 
+as it isn't too hard on implementors, and doesn't make other parts of 
+the language harder to use.
+
+In this case, I think that the extension is very easy, and makes lots of 
+code using arrays easier to write, and easier to understand.  The big 
+problem when designing abstractions in Ada, at least as I see it, is the 
+proliferation of declarations with junk names, especially junk names 
+that have to be visible. So in general, I think when we find cases in 
+Ada where junk types and names are required, we should look at 
+eliminating them.  The unconstrained array object case--bounded or 
+unbounded--has been one of my pet peeves, and while writing the previous 
+message I finally saw a way that it could be solved easily and cleanly. 
+
+Not that I haven't tried in the past.  I must have written the package 
+that is now Bounded_Strings several dozen times.  The unbounded version 
+used to come up much less often, but now that it is in the standard, 
+Unbounded_String gets much more use than Bounded_String.  Why?  Well 
+there is slightly more overhead /for the programmer/ with 
+Bounded_String: you have to instantiate a generic, which requires a junk 
+name.
+
+>For example, "array(String range <>) of Boolean" still requires a
+> hash-table generic, or some such.
+
+I can live with that, although I would prefer to think of that type as a 
+set of Strings.  For that abstraction the programmer has to have 
+knowledge that will determine the best hash-function, or even whether to 
+use hashing.  By the way, I started to try to figure out how many 
+elements that array has.  It seems to be much less than a googleplex 
+even assuming 64-bit Integer. A googleplex is 10**(10**100), this is 
+very roughly 10**(10**20).  Roughly in part because the number of 
+elements is actually a summation over all string lengths, times 
+(Integer'Last - 'Length) if the value of 'First for the String is 
+significant.
+
+****************************************************************
+
+From: Robert A. Duff
+Date: Tuesday, March 28, 2006  7:22 AM
+
+...
+> Our example looked like:
+>     package P.C is
+>         package T_Vector is new Vector (P.T);
+>         type Vector is new T_Vector.Vector with null record;
+>     end P.C;
+> 
+> The type declaration of "Vector" is only needed here so the type will be
+> visible via a limited with.
+
+Right.  I was assuming clients would use P.C.Vector, and ignore
+P.C.T_Vector.Vector.  I realize this is a pain when more than one type is
+involved, or things other than primitive ops are involved.
+
+...
+> The better solution would be to come up with a form of type renaming. That
+> would be more generally useful. I can't think of a great syntax for this,
+> but I'm sure someone else can:
+>      type renames T_Vector.Vector, T_Vector.Cursor;
+> This would work much like Bob's idea:
+>     * The types would have to be frozen (or this would be freezing). [That's
+> necessary so that we know the set of primitive operations.]
+>     * The type(s) would be declared here as subtypes, with the given simple
+> names.
+>     * The newly given (subtypes) would be visible to limited withs.
+>     * The primitive operations of the type(s) would be declared here as
+> renames of the originals, with the appropriate simple names.
+
+But currently limited withs do not know about subtype declarations.  We could
+change that.  But then, the example above can say "subtype Vector is
+T_Vector.Vector;", and we don't need the "type renames...".
+
+> Note that using two separate type renames would not work quite the same as a
+> single one, as you'd get multiple copies of any routines primitive to both
+> types. That's either illegal, or any calls would be ambiguous, and neither
+> is going to work right.
+> 
+> To make a Bob-like pronouncement, I'm not interested in a solution that
+> doesn't get rid of this extra type.
+
+I agree with that pronouncement.  But as always, I reserve the right to change
+my mind.  ;-)
+
+>... The naming issue is minor; 
+
+Agreed.
+
+>...indeed, I've
+> nearly convinced myself that it's better to have these things as separate
+> children than for them to be nested.
+
+Now you're (nearly) making a virtue out of necessity.
+
+****************************************************************
+
+From: Robert A. Duff
+Date: Tuesday, March 28, 2006  8:33 PM
+
+> Anyway, this is a very big deal to me. The check for 3.2.1(5) is
+> computationally very expensive. That because child units can be involved, so
+
+I'm having trouble picturing a cycle that crosses compilation unit boundaries
+(children or otherwise).  Please show me one, if possible.
+
+> I suspect that existing 3.2.1(5) checks don't recurse, and certainly don't
+> check outside of the current unit. Both of which are obviously wrong, given
+> this example.
+
+GNAT gives an error (junk.ads:32:10: circular type definition) on the
+following example, which has a 10-long cycle.  And it doesn't recurse
+infinitely.  ;-)
+
+  package Junk is
+
+      type T1 is private;
+
+      type T2 is
+          record
+              X: T1;
+          end record;
+
+      type T3 is array(Boolean) of T2;
+
+      type T4 is
+          record
+              X: T3;
+          end record;
+
+      type T5 is
+          record
+              X: T4;
+          end record;
+
+      type T6 is
+          record
+              X: T5;
+          end record;
+
+      type T7 is
+          record
+              X: T6;
+          end record;
+
+      type T8 is
+          record
+              X: T7;
+          end record;
+
+  private
+
+      type T1 is
+          record
+              X: T8;
+          end record;
+
+      X: T8;
+
+  end Junk;
+
+> And the privacy breakage is unacceptable.
+
+I don't like it, either.  But I think "unacceptable" is too strong.  The RM is
+clear (the cycle is illegal, even if hidden in private parts).  And I don't
+see any way to fix it, short of allowing cycles, or incompatibility.
+
+>... I would expect that you would hear
+> the same from Mr. Private.
+
+But Mr. Private's compiler is the only one I know of that correctly detects
+the error (in the private example)!
+
+> So I continue to believe that your problem is intractable, given the rules
+> of Ada as they are or reasonably could be. The Duff language may have
+> different results...
+
+Indeed.  There are no freezing rules in that language.  And all ABE checks are
+static.  And cyclic types are allowed.  The problem is, it doesn't get
+scrutinized by hoards of rabid language lawyers, so it's probably full of
+bugs.  ;-)
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Tuesday, March 28, 2006  5:18 PM
+
+> But currently limited withs do not know about subtype declarations. We could
+> change that.  But then, the example above can say "subtype Vector is
+> T_Vector.Vector;", and we don't need the "type renames...".
+
+I know, but I think that the issues are less of a concern in this limited case.
+If that isn't true, then I will go back to suggesting my hack (a special
+declaration of types available for limited with purposes), because a feature
+tailored to fix this problem can always be made to work. (But something more
+general is preferable.)
+
+...
+> >...indeed, I've
+> > nearly convinced myself that it's better to have these things as separate
+> > children than for them to be nested.
+>
+> Now you're (nearly) making a virtue out of necessity.
+
+No, it was a virtue before, too. Generally, when there is a choice between a
+nested package and a child package, it's better to choose the child. The
+"nearly" comes from the thinking that the added conceptual overhead isn't
+worth it for a tiny package (although I have to wonder why anyone would make
+it a package at all in that case).
+
+Anyway, the only user value to using nested packages rather than children is
+the fact that there is a bit less work to naming them in the context clause.
+All we'd need to fix that is some way to write an aggregate context clause.
+Your bulk renaming is one approach (although it duplicates everything);
+Tucker's original idea is another. Here's a third wild idea:
+
+How about a way to give a name to a (limited) set of library units for
+context clause purposes? The set would be composed of a parent and some
+children. Say, something like:
+   for with Bob_Blob use with Claw, Claw.Basic_Window, Claw.Frame_Window, Claw.Dialog;
+This would be compiled in place of a compilation unit (like a pragma). (If
+one allowed it in the parent package spec, you essentially get Tucker's
+original idea.) The effect would be similar to renaming the parent package
+and including the children as nested packages in that rename.
+
+Then, if you say:
+   with Bob_Blob;
+you could reference
+   Bob_Blob.Root_Window_Type -- A type in the parent.
+   Bob_Blob.Basic_Window -- One of the child packages.
+   Bob_Blob.Frame_Window.Frame_Window_Type -- A type in a child package.
+
+In your example, to make your aggregation, you'd simply say:
+   for with Better_P use with P, P.C;
+
+Humm, maybe this should have some renames like syntax. I'll leave that to
+others.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Tuesday, March 28, 2006  5:41 PM
+
+> > Anyway, this is a very big deal to me. The check for 3.2.1(5) is
+> > computationally very expensive. That because child units can be
+> > involved, so
+>
+> I'm having trouble picturing a cycle that crosses compilation
+> unit boundaries (children or otherwise).  Please show me one, if
+> possible.
+
+Humm, I remember having such a case the last time this was discussed, but I
+can't find it now.
+
+...
+> > And the privacy breakage is unacceptable.
+>
+> I don't like it, either.  But I think "unacceptable" is too strong. The RM is
+> clear (the cycle is illegal, even if hidden in private parts). And I don't
+> see any way to fix it, short of allowing cycles, or incompatibility.
+
+Well, first of all, if this cannot happen across units in the current language,
+then I don't much care about this example. And I don't think it is at all
+similar to the version you want introduce.
+
+In particular, if this can only happen in a single unit, and it is clearly
+illegal by the language rules, then the privacy issue cannot break a client.
+That's because no client can involve a loop (without explicit indirection
+somewhere). Moreover, if there is a loop here, the unit is illegal -- so it
+isn't going to persist for long.
+
+Moreover, there is no maintenance issue: if you have the ability to change
+some part of this unit's source code, then you can change some other part.
+Privacy is essentially irrelevant to the constructor of an abstraction;
+it's the client of the abstraction that cares.
+
+Contrast that to the instantiation case that you are promoting. The generic
+unit is completely separate, and has no idea how it will be used. The
+generic unit may be maintained by a separate group than the place of the
+instance. The notion that a change in the private part generic unit will
+cause client instantiations be illegal (without some change in the contract)
+is very uncomfortable. (Yes, I know that there already exist cases like
+that having to do with the recheck, but those too are very bad -- and
+we've worked at eliminating the worst offenders in Ada 2005.
+Most of the remaining cases are rare, or are in the visible contract
+[interfaces, for example]. Anything not in the contract is an inhibition to
+code sharing, for instance.)
+
+All this means that breaking privateness this way is a significant
+impediment to program maintenance. (While the existing example does not
+have much effect on maintenance.)
+
+In any case, don't forget that we couldn't find a semantics for such early
+instantiations that more than one or two implementers could even implement.
+Forcing implementers to redo all of freezing and elaboration and
+instantiation code isn't going to fly. (And if it does, you'll just
+end up with a standard that's widely ignored. Not good.)
+
+****************************************************************
+
+From: Robert A. Duff
+Date: Tuesday, March 28, 2006  6:22 PM
+
+> In any case, don't forget that we couldn't find a semantics for such early
+> instantiations that more than one or two implementers could even implement.
+> Forcing implementers to redo all of freezing and elaboration and
+> instantiation
+> code isn't going to fly. (And if it does, you'll just end up with a standard
+> that's widely ignored. Not good.)
+
+Uncle!
+
+****************************************************************
+
+From: Pascal Leroy
+Date: Wednesday, March 29, 2006  4:43 AM
+
+> (One simple fix would be to extend limited views to subtypes:
+> 
+> 	package P.Vectors is
+> 	   package T_Vectors is new Vectors (T);
+> 	   subtype Vector is T_Vectors.Vector;
+>          subtype Cursor is T_Vectors.Cursor;
+> 	end P.Vectors;
+> 
+> These subtypes aren't imported as limited views currently, 
+> and that means separate types have to be used. But I don't 
+> know off-hand what horrors that would introduce -- there 
+> probably is some.)
+
+The main reason for not allowing subtypes in limited views in the current
+model is that they are not useful in solving type circularities (remember,
+this is why limited views were invented).  A possible issue is that you
+cannot determine syntactically if a subtype is tagged or not, but I think
+that it would be OK to just assume that it isn't, although of course that
+would prevent its use as parameter or as the prefix of 'Class.
+
+****************************************************************
+
+From: Pascal Leroy
+Date: Wednesday, March 29, 2006  5:05 AM
+
+> I have a general comment on this issue:  In previous 
+...
+> All of these are legitimate concerns, but they're not fatal 
+> flaws. Yet we have allowed them to paralyze us.
+
+If you had attended the many meetings where numerous alternatives were
+considered, you would have, I guess, a different perspective on things.
+We were light-years away from any acceptable solution.  I think we were
+ready to compromise on the issues that you mention above, but all the
+solutions that we considered either didn't solve the problem, or created
+no end of trouble for implementations and for the language definition.
+
+> Yes, it breaks privacy.  But privacy is already broken
+> without any generics, as I pointed out in an e-mail on
+...
+> Of 4 compilers tested, only one correctly noted that this is 
+> illegal by 3.2.1(5).
+
+But this is totally unconvincing.  As far as I can tell, you cannot create
+a version of this example that would cross compilation units.  So yes, you
+can have a compilation error because of 3.2.1(5) here, but you will find
+it as soon as you compile Junk, and it won't affect clients.  The nasty
+cases are those where changes to a (possibly generic) package cause the
+clients to suddenly fail to compile.  Nothing like that here.
+
+> OK.  We would need to specify for each language-defined 
+> container whether it can be used cyclically.  User-defined 
+> ones are on their own (though I admit it's always sad to 
+> break privacy).
+
+If we fell that this is important (and I tend to believe that it is) we
+need a way to express it in the contract.  It's ludicrous to just put a
+sentence in the RM for the containers and ignore similar problems that
+users may run into.
+
+****************************************************************
+
+From: Pascal Leroy
+Date: Wednesday, March 29, 2006  6:15 AM
+
+> I suspect that existing 3.2.1(5) checks don't recurse, and 
+> certainly don't check outside of the current unit. Both of 
+> which are obviously wrong, given this example.
+
+Nonono.  Bob managed to confuse you, but it is not possible to build a
+variant of his example that crosses compilation units.  The reason is that
+as soon as you land in another compilation unit all the types there have
+been frozen long ago, so of course they cannot depend on the types
+declared in the current compilation unit.
+
+We implement this check correctly, I believe, and it is not at all
+computationally expensive.  Roughly, what we do when freezing a type is to
+traverse all its components, keeping track of the types that have already
+been visited (this traversal is pretty much required by 13.14(15) anyway).
+It we encounter a type that lives in another unit, we stop the traversal.
+If we encounter a type that we have already visited, we detect a violation
+of 3.2.1(5).
+
+The bottom line is that, if you have N types in your compilation unit, the
+cost of this processing is O(N*Log(N)), the most expensive part being the
+management of the set of types already visited (we do that using a
+balanced tree).
+
+> And the privacy breakage is unacceptable. I would expect that 
+> you would hear the same from Mr. Private. So I think a fix is 
+> worth having; certainly worth investigating and discussing.
+
+I really cannot get excited about a privacy breakage that involves a
+nested package and its enclosing library package.  It will be impossible
+to compile the unit anyway, so it's not going to impact clients.  The
+reason why privacy is important is that it must be possible to change a
+reusable component without impacting the legality of its clients.  Nothing
+of the sort here.
+
+> My thinking is that that is a property of the exported 
+> private type, so there should be some indication of that in 
+> the private type declaration. Something like:
+> 
+>     type List is private with indirection;
+
+You can get quite close to that with the current language:
+
+	type Guts (<>) is limited private;
+	type List is access all Guts;
+
+Provided that you don't export constructors for Guts, it's pretty much
+unusable by clients.  I realize that what you are proposing is more
+flexible, but I'm not sure if it's worth the added language complexity.
+
+Anyway, even if we invented new syntax and new rules, the default should
+be that, in the absence of more specific information, a private type might
+have components of the formal types. 
+
+****************************************************************
+
+From: Pascal Leroy
+Date: Wednesday, March 29, 2006  6:24 AM
+
+> In this case, I think that the extension is very easy, and 
+> makes lots of 
+> code using arrays easier to write, and easier to understand.
+
+I don't think that discriminated arrays (or anything of that nature) is
+"very easy", either from the standpoint of language definition or from the
+standpoint of implementations.  Issues like slicing and matching of
+generic formal arrays come to mind.
+
+> The big 
+> problem when designing abstractions in Ada, at least as I see it, is the 
+> proliferation of declarations with junk names, especially junk names 
+> that have to be visible. So in general, I think when we find cases in 
+> Ada where junk types and names are required, we should look at 
+> eliminating them.
+
+I strongly agree with this statement, but I think the right way to address
+it not to invent new constructs, but to allow more "anonymous" constructs.
+That proved productive for access types, so I think it's worth considering
+in other cases.  In the case that you mention, what I would really like to
+write is:
+
+	type Variable_Sized_Array(Size: Integer := 0) is
+	   record
+	      <anonymous> : Int_Array(1..Size); -- Better syntax needed.
+	   end record;
+
+And then I would like to be able to write Some_Variable_Sized_Array (3)
+and have it go to the component.  I realize that in some cases there might
+be ambiguities as to whether we are talking about the record or its array
+component, but it doesn't seem worse than what we have today with implicit
+dereferencing.
+
+****************************************************************
+
+From: Robert A. Duff
+Date: Wednesday, March 29, 2006  6:27 AM
+
+>...  It's ludicrous to just put a
+> sentence in the RM for the containers and ignore similar problems that
+> users may run into.
+
+That's what we do for composability of "=".
+I agree that it's ludicrous.
+
+****************************************************************
+
+From: Pascal Leroy
+Date: Wednesday, March 29, 2006  6:31 AM
+
+> I've nearly convinced myself that 
+> it's better to have these things as separate children than 
+> for them to be nested. The extra type causes complications 
+> all over, requiring extra type conversions somewhere and/or 
+> screwing up the visibility of things.
+
+No, I disagree.  I am not happy with the "workaround" that I presented for
+two reasons: (1) it requires an extra type with the attendant conversions;
+and (2) it requires this silly child unit for the sole purpose of being
+able to use a limited view.
+
+These issues make the workaround unusable as far as I am concerned.
+
+****************************************************************
+
+From: Robert A. Duff
+Date: Wednesday, March 29, 2006  7:10 AM
+
+> 	type Variable_Sized_Array(Size: Integer := 0) is
+> 	   record
+> 	      <anonymous> : Int_Array(1..Size); -- Better syntax needed.
+> 	   end record;
+> 
+> And then I would like to be able to write Some_Variable_Sized_Array (3)
+> and have it go to the component.  I realize that in some cases there might
+> be ambiguities as to whether we are talking about the record or its array
+> component, but it doesn't seem worse than what we have today with implicit
+> dereferencing.
+
+Hmm.  For "X: constant Variable_Sized_Array := (3, 4, 5, 6);"
+is X.Size 3 or 4?
+
+****************************************************************
+
+From: Pascal Leroy
+Date: Wednesday, March 29, 2006  7:29 AM
+
+> Hmm.  For "X: constant Variable_Sized_Array := (3, 4, 5, 6);" 
+> is X.Size 3 or 4?
+
+I think we would only want to go to the anonymous component in contexts
+that involve indexing or slicing.  So I could imagine some contexts
+involving conversions being annoying, but in the above example you would
+be assigning the entire object.
+
+Surely a half-baked idea...
+
+****************************************************************
+
+From: Robert A. Duff
+Date: Wednesday, March 29, 2006 12:39 PM
+
+Hmm.  I'm not sure I agree.  I'll avoid what Randy calls a Duff Pronouncement
+(of the form "if it doesn't solve the aggregate problem, it's not a complete
+solution").  ;-)
+
+But I do think the aggregate (and string literal) issue is important.
+
+If I have:
+
+    X: constant String := "Hello, world.";
+    Do_Something(X);
+
+but I want the lower bound to be exactly 1 always, I can say:
+
+    type My_String(Length: Natural) is
+        record
+            S: String(1..Length);
+        end record;
+
+    X: constant My_String := (Length => 13, S => "Hello, world.");
+    Do_Something(X.S);
+
+Having to write that ".S" is a minor annoyance,
+compared to having to count those 13 characters!
+
+Same issue applies to aggregates.
+
+> Surely a half-baked idea...
+
+Well, that's where fully-baked ideas come from.  ;-)
+
+****************************************************************
+
+From: Tucker Taft
+Date: Wednesday, March 29, 2006  1:17 PM
+
+Anonymous component names sounds like a bit
+of a nightmare (quite different from anonymous
+types).  For me, I would still prefer the
+original 9X proposal of:
+
+   type My_String(Length : Natural) is
+     array(1..Length) of Character;
+
+or a slight variation:
+
+   type My_String(Length : Natural) is new String(1..Length);
+
+The latter is closer to the kind of "wrapper" you
+were envisioning.
+
+For both of the above, one would presume that the discriminant
+could be referenced but not explicitly set.  It is inferred
+from the 'Last bound of the "underlying" array.  The type would
+remain an array type, with array aggregates, array indexing,
+slicing (with automatic sliding, presumably), etc.
+But it would also allow references to the discriminant,
+and subtypes would be defined via discriminant constraints
+rather than index constraints.
+
+****************************************************************
+
+From: Tucker Taft
+Date: Wednesday, March 29, 2006  9:17 PM
+
+>>   Perhaps what we really need is a new kind of formal
+>>   generic type, perhaps a "formal limited incomplete type."
+>>   You would be forced to use it only with a level of
+>>   indirection, but you would be allowed to instantiate
+>>   it with an incompletely-defined type.
+
+Randy,
+Thanks for taking the time to respond on this
+idea.  You have pointed out that the big question
+is what, if anything, can you do with this new kind
+of formal type in the generic body.  Presumably in
+the spec it is treated as an incomplete type (potentially
+a tagged incomplete type if we allow "tagged" in
+the formal type declaration).  This would mean that
+only "access" parameters are allowed if not tagged,
+and only access results (even if tagged).
+That pretty much rules out using this for any of the
+current containers packages, since they don't
+require the element type to be tagged, and have plenty
+of parameters and result types that are of the element type.
+
+In the body, it would seem we would at a minimum need
+to allow assignment and allocators.  Otherwise, as you
+point out, it would be pretty hard to define any sort
+of "container."  If the formal type is definite, we
+would presumably want to allow default initialization.
+As you pointed out, this is beginning to imply that we
+will need "thunks" for "assignment" and "size", and
+for default initialization if definite.  Most implementations
+already have something like this for tagged types, to
+support class-wide types.  Creating such thunks for all
+types would be painful.  Which comes around to making
+me think that perhaps all we should allow are formal
+*tagged* incomplete.  The syntax also then becomes pretty
+obvious:
+
+     type T is tagged;
+and perhaps
+     type T is tagged limited;
+
+with an optional "(<>)" to indicate indefiniteness.
+
+This makes the proposal significantly less interesting
+as far as solving the general "T containing Vector of T"
+problem, I suppose.  Oh well...
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Thursday, March 30, 2006  9:46 PM
+
+> No, I disagree.  I am not happy with the "workaround" that I presented for
+> two reasons: (1) it requires an extra type with the attendant conversions;
+> and (2) it requires this silly child unit for the sole purpose of being
+> able to use a limited view.
+>
+> These issues make the workaround unusable as far as I am concerned.
+
+Various solutions to both (1) and (2) have been proposed, with the idea of
+making the access to the "silly child" easier, rather than trying to
+eliminate it.
+
+In any case, the existence of your "workaround" eliminates the urgency of
+finding a fix. I've been pushing this issue because I've been under the
+impression that writing code like this was impossible. If it is not
+impossible, just annoying, it's much harder to get worried about it. There
+are a lot of things in Ada that are annoying: having to say "access" when
+you mean "in out" for tagged objects passed to functions, and the mess
+needed to write an iterator come to mind immediately. I don't see any reason
+for this problem to be considered more important than those.
+
+I especially can't get concerned about Tucker's "signature package"
+"problem", which apparently can be solved simply by declaring the instance
+as a child. Gee, that's awful. :-)
+
+I don't mind trying to make these things easier in some way, but I'd rather
+get "in out" parameters for functions (at least for tagged objects, where
+the semantics is exactly equivalent to "access"), or real iterators, or
+better ways to pass data with exceptions, or ...
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Thursday, March 30, 2006 10:02 PM
+
+> Thanks for taking the time to respond on this
+> idea.
+
+Well, someone had to. No one much has responded to my ideas for making types
+in instances visible to limited with, nor my idea for allowing the renaming
+of a group of children (a better version of one the ideas that started this
+thread).
+
+> You have pointed out that the big question
+> is what, if anything, can you do with this new kind
+> of formal type in the generic body.
+
+Right, that is key.
+
+...
+> Which comes around to making
+> me think that perhaps all we should allow are formal
+> *tagged* incomplete.
+...
+> This makes the proposal significantly less interesting
+> as far as solving the general "T containing Vector of T"
+> problem, I suppose.  Oh well...
+
+I was leaning that way, too.
+
+I suppose this is another case where only tagged types work "right". I can't
+get too concerned that it doesn't work for container of Boolean, and
+significant composite types probably ought to be tagged anyway because they
+work "right" for equality, 'Access for parameters, the availability of
+prefix calls and extensions, etc. (We made the containers tagged for this
+sort of reason.) It does mean this is only likely to be useful for new code,
+but that doesn't seem too bad -- people don't generally go back and rip out
+the old work-arounds just because something new is available.
+
+But I do agree that containers using this concept would have to be different
+in several significant ways from the Ada.Containers. Not sure if that is
+real problem or not (certainly, any such containers would have to be in
+addition to the ones we have as opposed to replacing them).
+
+****************************************************************
+
+From: Pascal Leroy
+Date: Friday, March 31, 2006 12:57 AM
+
+> In any case, the existence of your "workaround" eliminates 
+> the urgency of finding a fix.
+
+Gottverdammt!  I wish I had shut up!
+
+> I don't mind trying to make these things easier in some way, 
+> but I'd rather get "in out" parameters for functions (at 
+> least for tagged objects, where the semantics is exactly 
+> equivalent to "access"), or real iterators, or better ways to 
+> pass data with exceptions, or ...
+
+I agree that these are all interesting and useful topics to study.
+
+****************************************************************

Questions? Ask the ACAA Technical Agent