CVS difference for ais/ai-30302.txt

Differences between 1.5 and version 1.6
Log of other versions for file ais/ai-30302.txt

--- ais/ai-30302.txt	2004/06/10 05:39:58	1.5
+++ ais/ai-30302.txt	2004/06/25 00:55:46	1.6
@@ -12567,6 +12567,142 @@
 
 ****************************************************************
 
+From: Matthew Heaney
+Sent: Thursday, June 10, 2004  10:32 AM
+
+> It's very clear that this is a bounded error, and we're *not* requiring
+> implementations to detect this case (in this specific example, because
+> Delete is called on an element to the left). But we *allow* it to be
+> detected. I thought we had agreed that we didn't want the overhead of
+> detecting these kinds of errors.
+
+OK, I just wanted to make sure.
+
+
+The other thing I forget to mention is that the following operations are 
+in the list package but not the vector package:
+
+
+    procedure Delete (Container : in out List;
+                      Item      : in     Element_Type);
+
+
+    generic
+       with function Predicate (Element : Element_Type)
+          return Boolean is <>;
+    procedure Generic_Delete (Container : in out List);
+
+
+    procedure Reverse_List (Container : in out List);
+
+
+    generic
+       with function Predicate (Element : Element_Type)
+          return Boolean is <>;
+    function Generic_Find (Container : List;
+                           Position  : Cursor := No_Element)
+       return Cursor;
+
+
+    generic
+       with function Predicate (Element : Element_Type)
+          return Boolean is <>;
+    function Generic_Reverse_Find (Container : List;
+                                   Position  : Cursor := No_Element)
+       return Cursor;
+
+
+There's no technical reason they should be in the list but not the 
+vector.  Either we can add them to vector, or get rid of them for list.
+
+
+Here's another idea.  We already have a Generic_Update, but another 
+useful operation might be some kind of query operation, that either 
+returns Boolean or a type you pass in as a generic formal.  Something like:
+
+generic
+    type Result_Type (<>) is limited private;
+    function Process (E : ET) return Result_Type is <>;
+function Generic_Query (Position : Cursor) return Result_Type;
+
+Of course, a user could implement this as (here, for a Boolean Result_Type):
+
+function Query (P : C) return Boolean is
+    Result : Boolean;
+
+    procedure Process (E : in out ET) is
+    begin
+       Result := Predicate (E); -- some algorithm
+    end;
+
+    procedure Update is new Generic_Update;
+begin
+    Update (P);
+    return Result;
+end;
+
+The awkward case is when the Result_Type actual type is indefinite.  For 
+example, were it type String you would have to use an unbounded_string 
+or whatever as the temporary (but maybe that's not such a big deal).
+
+Clearly you can implement a query-style function from the update 
+modifier operation, but I wasn't sure whether that's possible in all 
+cases for all possible return types, and if so whether this warrants the 
+introduction of a dedicated operation.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, June 10, 2004  6:50 PM
+
+...
+> There's no technical reason they should be in the list but not the
+> vector.  Either we can add them to vector, or get rid of them for list.
+
+I'd be wary of adding too many rarely used routines to these containers.
+Those just make the containers harder to learn and harder to implement with
+little additional benefit.
+
+Unbounded_Strings has a large number of rarely used routines, and yet it
+never seems to have the odd routine I actually need. So, that actually
+increases the frustration level, because you'd think that in so many
+routines, every plausible need would be met. When there are fewer routines,
+the expectation level is lower, too, and you wouldn't feel quite so
+ripped-off.
+
+In the routines you mentioned, I think that the generic routines are too
+specialized - it would be rare that you both could match their usage pattern
+*and* would remember that they exist. Delete by item seems error-prone if
+there are multiple identical items in the container (does it delete just one
+or all of them? Explain your choice, and why the user would expect that over
+the other possibility.) Reverse_List (which probably should just be called
+"Reverse") doesn't seem that useful, and is masking a lot of work. So I'd
+probably dump the whole lot. But I do agree that List and Vector should be
+the same, whatever is decided.
+
+> Here's another idea.  We already have a Generic_Update, but another
+> useful operation might be some kind of query operation, that either
+> returns Boolean or a type you pass in as a generic formal.
+> Something like:
+>
+> generic
+>     type Result_Type (<>) is limited private;
+>     function Process (E : ET) return Result_Type is <>;
+> function Generic_Query (Position : Cursor) return Result_Type;
+
+This seems too specialized to me. Most of the time, it would make just as
+much sense to write a function of the Element. Besides, this seems like it
+would be illegal if AI-318 is passed as currently planned, since limited
+unconstrained types will not be allowed to be returned. So there is a
+contract issue here (having a function that has to be able to both
+build-in-place and return-by-copy seems like a very nasty case for generic
+sharing implementations).
+
+In any case, we need to avoid "feeping creaturism" here. KISS definitely
+applies!
+
+****************************************************************
+
 From: Pascal Obry
 Sent: Wednesday, June 9, 2004  10:43 AM
 
@@ -12843,53 +12979,295 @@
 
 ****************************************************************
 
-From: Matthew Heaney
-Sent: Wednesday, June 9, 2004  9:31 AM
+From: Robert A. Duff
+Sent: Thursday, June 10, 2004  7:45 AM
+
+Tuck says:
+
+> How about "Maximum_Length" and "Set_Maximum_Length" in place
+> of Size and Resize?
+
+I don't really like "Maximum_Length", because there actually *is* no max
+length -- the whole point is these things can grow arbitrarily large.
+I believe STL calls them "capacity" and "reserve".
 
+Pretty much anything would be better than "Size", for the reasons Pascal
+stated.
+
 ****************************************************************
 
 From: Matthew Heaney
-Sent: Wednesday, June 9, 2004  9:31 AM
+Sent: Thursday, June 10, 2004  10:10 AM
+
+Well, it does describe when expansion happens.  How about:
+
+function Expansion_Length
+   (Container : in Map) return Size_Type;
+
+procedure Set_Expansion_Length
+   (Container : in out Map;
+    Length    : in     Size_Type);
 
 ****************************************************************
 
-From: Matthew Heaney
-Sent: Wednesday, June 9, 2004  9:31 AM
+From: Alexander E. Kopilovich
+Sent: Thursday, June 10, 2004  11:31 AM
+
+Another proposition:
+
+  function Extent  -- or Current_Extent
+
+and
+
+  procedure Set_Extent  -- correspondily, Set_Current_Extent
+
+
+But perhaps the best would be to say straight:
+
+function Reserved_Length    -- or Reserved_Size
+
+and
+
+procedure Set_Reserved_Length  -- correspondily, Set_Reserved_Size
 
 ****************************************************************
 
-From: Matthew Heaney
-Sent: Wednesday, June 9, 2004  9:31 AM
+From: Tucker Taft
+Sent: Thursday, June 10, 2004  1:42 PM
+
+> But perhaps the best would be to say straight:
+> 
+> function Reserved_Length   
+> 
+> and
+> 
+> procedure Set_Reserved_Length 
+
+I like these.  "Capacity" is pretty much a synonym for
+"Maximum_Length".  Both need the word "Current" added to
+make it clear these are expandable.
+"Reserved" has just the right connotation.
+
+By the way, I agree that there seems no reason not to
+allow Set_Reserved_Length to specify a smaller length,
+though we then want Reserved_Length to be allowed to
+return a value larger than the value most recently set
+by Set_Reserved_Length.  Which might argue for changing
+the "set" procedure's name to "Set_Minimum_Reserved_Length"
+and the function's name to "Actual_Reserved_Length" to
+be crystal clear.
 
 ****************************************************************
 
-From: Matthew Heaney
-Sent: Wednesday, June 9, 2004  9:31 AM
+From: Alexander E. Kopilovich
+Sent: Thursday, June 10, 2004  5:13 PM
+
+Perhaps for this purpose "Provide_Reserved_Length" would be even better
+(again, more straigt) than "Set_Minimum_Reserved_Length".
 
+And additionally, as "provide" (unlike "set") is somehow uncertain about
+the upper limit, there will be less need for the prefix "Actual_" before
+"Reserved_Length".
+
 ****************************************************************
 
-From: Matthew Heaney
-Sent: Wednesday, June 9, 2004  9:31 AM
+From: Nick Roberts
+Sent: Friday, June 11, 2004  9:13 PM
+
+I like these suggestions. I quite like 'Actual_Reserved_Length', but I think
+it's not really necessary, since there is no other function
+('Requested_Reserved_Length' or some such) for it to be contrasted with.
+
+Perhaps a consensus is coming close to:
 
+- rename the term 'size' as 'reserved length';
+
+- rename the 'Size' functions as 'Reserved_Length';
+
+- rename the 'Resize' procedures as 'Request_Reserved_Length'.
+
+I would also like to suggest:
+
+- rename the type 'Size_Type' as 'Count' or 'Count_Type'.
+
+My justification for this is that the term 'size' is mainly used in
+connection with storage units, so some potential for confusion would be
+easily avoided by a different name, and a type 'Count' fulfilling a very
+similar role is declared in the Ada.*_IO packages.
+
+I would like to reiterate my suggestions that:
+
+- the Request_Reserved_Length (Resize) procedures are permitted to reduce
+the reserved length (size) of a container, but that in any case (reduction
+or expansion) any actual change to the reserved length (size) remains
+implementation defined;
+
+- an explicit expansion factor is supported, as in my previous post.
+
+My justification for the first is that it would not be sensible to formally
+test whether an implementation obeyed a more stringent definition. The
+Reserved_Length (Size) functions should return the actual reserved length
+(size), but again, it would probably not be sensible to try to formally test
+this (and it may not be possible).
+
+My justification for the second is that there will often be situations where
+the user (of the proposed container packages) knows better than the
+implementation what the expansion factor should be, and in such cases the
+implementation default for deciding by how much to expand a container
+(whether by a simple factor or some other method) is likely to be very
+inappropriate. [Sorry about numbering this point '(4)' in my previous post;
+it should have been '(5)'.]
+
 ****************************************************************
 
-From: Matthew Heaney
-Sent: Wednesday, June 9, 2004  9:31 AM
+From: Michael F. Yoder
+Sent: Saturday, June 12, 2004  9:18 AM
+
+>Perhaps a consensus is coming close to:
+>
+>- rename the term 'size' as 'reserved length';
+>
+>- rename the 'Size' functions as 'Reserved_Length';
+>
+>- rename the 'Resize' procedures as 'Request_Reserved_Length'.
+
+If there is such a consensus, I'll add my support to it.  These seem 
+like good ideas.
 
+>I would also like to suggest:
+>
+>- rename the type 'Size_Type' as 'Count' or 'Count_Type'.
+>
+>My justification for this is that the term 'size' is mainly used in
+>connection with storage units, so some potential for confusion would be
+>easily avoided by a different name, and a type 'Count' fulfilling a very
+>similar role is declared in the Ada.*_IO packages.
+
+I agree.
+
+>I would like to reiterate my suggestions that:
+>
+>- the Request_Reserved_Length (Resize) procedures are permitted to reduce
+>the reserved length (size) of a container, but that in any case (reduction
+>or expansion) any actual change to the reserved length (size) remains
+>implementation defined;
+
+I strongly agree.  Requiring that the user write the size reduction code 
+via a copy forecloses even the possibility of a reduction that avoids 
+copying.
+
+>- an explicit expansion factor is supported, as in my previous post.
+>
+>My justification for the first is that it would not be sensible to formally
+>test whether an implementation obeyed a more stringent definition. The
+>Reserved_Length (Size) functions should return the actual reserved length
+>(size), but again, it would probably not be sensible to try to formally test
+>this (and it may not be possible).
+>
+>My justification for the second is that there will often be situations where
+>the user (of the proposed container packages) knows better than the
+>implementation what the expansion factor should be, and in such cases the
+>implementation default for deciding by how much to expand a container
+>(whether by a simple factor or some other method) is likely to be very
+>inappropriate. [Sorry about numbering this point '(4)' in my previous post;
+>it should have been '(5)'.
+
+I'm less enthusiastic about the expansion factor, but I don't oppose it.
+
 ****************************************************************
 
-From: Matthew Heaney
-Sent: Wednesday, June 9, 2004  9:31 AM
+From: Robert A. Duff
+Sent: Monday, June 14, 2004  8:55 AM
+
+Mike Yoder wrote:
 
+> Nick Roberts wrote:
+> 
+> >- the Request_Reserved_Length (Resize) procedures are permitted to reduce
+> >the reserved length (size) of a container, but that in any case (reduction
+> >or expansion) any actual change to the reserved length (size) remains
+> >implementation defined;
+> >
+> I strongly agree.  Requiring that the user write the size reduction code 
+> via a copy forecloses even the possibility of a reduction that avoids 
+> copying.
+
+The STL guarantees that the reserved size is at least that requested.
+This is important because it means that cursors/iterators that
+point into the data structure do not become invalid while
+appending (up to that reserved size).
+
 ****************************************************************
 
-From: Matthew Heaney
-Sent: Wednesday, June 9, 2004  9:31 AM
+From: Nick Roberts
+Sent: Sunday, June 20, 2004  1:53 PM
+
+However, the semantics required by the current AI-302 is clearly different.
+
+The relevant wording is:
+
+   A Cursor value is *ambiguous* if any of the following have occurred
+   since it was created:
+     * Insert or Delete has been called on the vector that contains the
+       element the cursor designates with an index value (or a cursor
+       designating an element at such an index value) less than or equal
+       to the index value of the element designated by the cursor;
+     * The vector that contains the element it designates has been
+       passed to an instance of Generic_Sort.
 
+and:
+
+   A Cursor value is *invalid* if any of the following have occurred
+   since it was created:
+     * The vector that contains the element it designates has been
+       finalized;
+     * The vector that contains the element it designates has been
+       used as the Source or Target of a call to Move;
+     * The element it designates has been deleted.
+
+   The result of "=" or Has_Element is unspecified if it is called with
+   an invalid cursor parameter. Execution is erroneous if any other
+   subprogram declared in Containers.Vectors is called with an
+   invalid cursor parameter, or if the cursor designates an element in
+   a different vector object than the appropriate one specified in the
+   call.
+
+   AARM Notes:
+   The list above (combined with the bounded error cases) is
+   intended to be exhaustive. In other cases, a cursor value
+   continues to designate its original element. For instance,
+   cursor values survive the appending of new elements.
+   End AARM Notes.
+
+Cursors are not permitted to become ambiguous or invalid solely because of
+internal copying (as a result of automatic extension).
+
 ****************************************************************
 
-From: Matthew Heaney
-Sent: Wednesday, June 9, 2004  9:31 AM
+From: Randy Brukardt
+Sent: Wednesday, June 23, 2004  9:43 PM
+
+Right. That's an important property: cursors do not become invalid because
+of an action that is outside of the user's control. And memory management in
+a container is outside of the user's control.
+
+Resize (I forget the new name we settled on, so I'll use the old one for
+now) is purely a performance enhancing routine. The only requirement is that
+Size (ditto on the name) returns the value most recently passed into Resize,
+or something larger. There's an AARM note suggesting to implementors that
+Resize allocate at least the specified memory, but of course that is
+untestable and cannot be specified in normative language of the standard.
+
+****************************************************************
+
+From: Simon Wright
+Sent: Friday, June 11, 2004  3:03 AM
+
+> possibility.) Reverse_List (which probably should just be called
+> "Reverse")
+
+If it wasn't a reserved word!
+
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent