CVS difference for ai12s/ai12-0266-1.txt

--- ai12s/ai12-0266-1.txt	2018/06/16 02:09:59	1.5
+++ ai12s/ai12-0266-1.txt	2018/06/30 00:53:42	1.6
@@ -1,4 +1,4 @@
-!standard 5.5.1(4/3)                                  18-06-15  AI12-0266-1/03
+!standard 5.5.1(4/3)                                  18-06-16  AI12-0266-1/04
 !standard 5.5.1(6/4)
 !standard 5.5.1(11/3)
 !standard 5.5.2(4/3)
@@ -641,10 +641,24 @@
 an optimal number of loop parameters to be setup by the Split call, so long as
 the number of splits is not greater than the advised_split parameter.
 
+This proposal allows the container implementer a fair amount of flexibility
+in deciding how to implement the cursor array stored in the iterator object.
+In general, an implementor should allow for as many elements in the cursor
+array, as there are cores on the multicore processor. But one could still
+decide to use a fixed sized array with enough elements
+to provide good parallelism for most typical processors available today.
+For instance, a fixed size cursor array of size 64 elements might be a reasonable
+size to provide good parallelism for most uses. On the other hand, it might
+make sense to allocate the cursor array dynamically during the call to Split.
+Then the array can be sized to match any number of cores. Another advantage of
+dynamic allocation is that the storage would not be needed for iterators associated
+with non-parallel loops. The iterator types of the containers are controlled types, 
+so finalization of the iterator objects is already part of the iteration model. 
+
 It would have been nice to specify a post condition for the Split call something
 like;
 
-with Post => (for all I in 1 .. Object.Split_Count =>
+  with Post => (for all I in 1 .. Object.Split_Count =>
                  Has_Element (Object.Get_Cursor (I)))
 
 However, this is not allowed because Has_Element cannot be called during
@@ -657,14 +671,15 @@
 
 Another Post condition that would have been nice would be to add to Get_Cursor,
 
- with Post => (if Index = Object.Split_Count + 1 then Has_Element (Get_Cursor'Result) = False,
+  with Post => (if Index = Object.Split_Count + 1 
+                then Has_Element (Get_Cursor'Result) = False)
 
- but Has_Element cannot be called here, and we would need to add No_Element as a
- formal object to the package, which would break compatibility.
+but Has_Element cannot be called here, and we would need to add No_Element as a
+formal object to the package, which would break compatibility.
 
- We could consider adding these as Pre and Post contracts in the derived types
- in each of the containers, but the iterator types are not declared in the
- public part of the package, so it seems to be not worthwhile to do so.
+We could consider adding these as Pre and Post contracts in the derived types
+in each of the containers, but the iterator types are not declared in the
+public part of the package, so it seems to be not worthwhile to do so.
 
 
 !ASIS
@@ -1187,6 +1202,104 @@
 the need to describe these restrictions and results in English. And they 
 wouldn't apply to user-defined iterators if you only put them into the 
 container.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Saturday, June 16, 2018  12:21 AM
+
+> For the record, I one editorial fix.
+> 
+> Part of the interface referenced the package "Ada202x". I presume this 
+> is something you used in your testing, since there is no such thing 
+> proposed here or anywhere else (nor did it appear in the previous version of
+> the AI). So I replaced all of those with "Ada".
+
+Yes, that was just for testing, I forgot to do the change you did this time 
+round.
+
+> I'd probably add a bit of discussion similar to our recent 
+> back-and-forth on how the cursor array could get implemented in the 
+> iterator object. Some people might be concerned about the apparent 
+> need for dynamic allocation, and that should explicitly addressed.
+
+I have attached another version with the discussion section updated to mention 
+the possibility of implementation using fixed size array vs dynamic allocation. 
+[This is version /04 of the AI - Editor.]
+
+> ...
+>> I would have liked to specify post conditions that check that 
+>> Has_Element(Get_Cursor (I)) for all I in 1 ..
+>> Object.Split_Count is true after calling Split, or a post condition 
+>> for Get_Cursor such as Post => (if Index = Object.Split_Count + 1 
+>> then Has_Element(Get_Cursor'Result) = False
+>> 
+>> But the compiler tells me that one cannot use Has_Element in a Pre or 
+>> Post condition in this package because the call involves a non tagged 
+>> incomplete type
+>> (Cursor)
+> 
+> That sounds correct. Perhaps the rule is a bit more restrictive than 
+> it needs to be (one could allow the calls and then require a recheck 
+> for an instance - an assume-the-best rule), but changing that doesn't 
+> sound pleasant.
+
+The more I think about this, the more I think one ought to be able to specify 
+such class-wide pre and post conditions for abstract subprograms.
+
+I wonder if there might be a way to relax the rules in a simple way to allow 
+this at least. Anyway, you are probably right that it might not be pleasant, 
+but maybe something to consider if it would be worthwhile, at some point.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, June 16, 2018  2:56 AM
+
+> > I'd probably add a bit of discussion similar to our recent 
+> > back-and-forth on how the cursor array could get implemented in the 
+> > iterator object. Some people might be concerned about the apparent 
+> > need for dynamic allocation, and that should explicitly addressed.
+> 
+> I have attached another version with the discussion section updated to 
+> mention the possibility of implementation using fixed size array vs 
+> dynamic allocation.
+
+You'll excuse me if I don't post this now; it's 12 hours past the deadline,
+I've already posted the agenda and the files and loaded my laptop and there's
+water on the floor in here from a severe thunderstorm that just went thru...
+ 
+> > 
+...
+> > That sounds correct. Perhaps the rule is a bit more restrictive than 
+> > it needs to be (one could allow the calls and then require a recheck 
+> > for an instance - an assume-the-best rule), but changing that 
+> > doesn't sound pleasant.
+> > 
+> 
+> The more I think about this, the more I think one ought to be able to 
+> specify such class-wide pre and post conditions for abstract 
+> subprograms.
+
+The problem has nothing to do with preconditions of abstract subprograms.
+It's that you're doing it in a generic with a formal incomplete type that 
+isn't supposed to be used in any way other than to declare access types and
+subprogram parameters. And that was because we needed this generic to work on
+a *private* cursor. And you might remember that we were never able to find an
+adequate solution for *that* problem.
+
+> I wonder if there might be a way to relax the rules in a simple way to 
+> allow this at least.
+> Anyway, you are probably right that it might not be pleasant, but 
+> maybe something to consider if it would be worthwhile, at some point.
+
+I was thinking that we might be able to allow it in a generic if we require 
+the recheck. However, the recheck would fail in this case (the type being
+private) so I don't think that helps much. In any case, incomplete types are 
+not supposed to have any sort of object created for them, and allowing this 
+case without allowing anything that causes real trouble sounds painful. It 
+would have been better if we didn't need to use this hack to get an instance
+of a private type - but we *know* that was painful.
 
 ****************************************************************