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.
****************************************************************
Questions? Ask the ACAA Technical Agent