CVS difference for ais/ai-30302.txt

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

--- ais/ai-30302.txt	2005/10/31 05:18:52	1.19
+++ ais/ai-30302.txt	2005/11/16 06:51:24	1.20
@@ -32543,22 +32543,398 @@
 ****************************************************************
 
 From: Matthew Heaney
-Sent: Friday, June 17, 2005  9:31 AM
+Sent: Tuesday, November 15, 2005  9:20 PM
 
+Here are a few comments on the vectors section of the latest AI-302 draft.
+
+The first line of my copy of the draft says:
+
+!standard A.18 (00)   05-09-20  AI95-00302-03/15
+
+I got the draft here:
+
+http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-20302.TXT?rev=1.23
+
+
+Comment #1:
+
+The draft says:
+
+BEGIN QUOTE:
+
+Some operations are assumed not to replace elements. During the execution 
+of such an operation, a subprogram is said to *tamper with elements* of a 
+vector object V if:
+
+   * it tampers with cursors of V; or
+   * it replaces one or more elements of V, that is, it calls the
+     Replace_Element, Reverse_Elements, or Swap procedures or the Sort or
+     Merge procedures of an instance of Generic_Sorting with V as a
+parameter.
+
+END QUOTE.
+
+I'm having trouble parsing the first sentence, in conjunction with the 2nd
+bullet.
+
+The first sentence says that some operations do not replace elements.  But
+the 2nd bullet says that Replace_Element (which does replace elements) is
+one of the operations that don't replace elements.
+
+
+Comment #2:
+
+The AARM Note in the description of Replace_Element says:
+
+BEGIN QUOTE:
+
+AARM Note: Replace_Element and Update_Element are the only ways that an
+element
+can change from empty to non-empty.
+
+END QUOTE.
+
+Did the semantics change here? IIRC, it used to be the case that only
+Replace_Element could be used to do that "reliably."  In the statement
+above, you don't qualify the use of Update_Element for this purpose (to
+change the empty state of an element), so I interpret that to mean that
+Update_Element is now equivalent to Replace_Element.  Were the semantics
+liberalized?  Has Update_Element really become portable?  (Or perhaps there
+are other rules elsewhere in the language that handle the case of using
+Update_Element to manipulate an empty element.)
+
+
+Comment #3:
+
+The description of Insert says:
+
+BEGIN QUOTE:
+
+procedure Insert (Container : in out Vector;
+                  Before    : in     Extended_Index;
+                  New_Item  : in     Vector);
+
+...If the current vector capacity is less than or equal to NL,
+Reserve_Capacity (Container, NL) is called to increase the vector capacity.
+
+END QUOTE.
+
+
+Shouldn't the first part of that sentence say just "less than" instead of
+"less than or equal"?
+
+
+Comment #4:
+
+The semantics of Delete are described as follows:
+
+BEGIN QUOTE:
+
+procedure Delete (Container : in out Vector;
+                  Position  : in out Cursor;
+                  Count     : in     Count_Type := 1);
+
+... and then Position is set to No_Element.
+
+END QUOTE.
+
+I have already argued in a previous review that I don't like these
+semantics.  It used to be the case (prior to the post-York release) that on
+return, cursor position would designate the first element past the range of
+elements deleted.  These semantics duplicate the C++ STL idiom:
+
+cont_t c;
+//...
+iter_t i = ...
+//...
+i = c.erase(i);
+
+If I do a multi-element delete, then there's no way for me to know what the
+first element is past the deleted range!  Which means if I care about that
+that I have to use a loop, which defeats the purpose of having the Count
+parameter.
+
+To buttress my argument, consider the behavior of Insert:
+
+BEGIN QUOTE:
+
+procedure Insert (Container : in out Vector;
+                  Before    : in     Cursor;
+                  New_Item  : in     Vector;
+                  Position  :    out Cursor);
+
+... Position is set to To_Cursor (Container, T).
+
+END QUOTE.
+
+Note that here, we at least have a way to recover a pointer to the beginning
+of
+the range of the newly-inserted items.  The problem with the new semantics
+for
+Delete is that you haven't provided a clean way to designate range that
+follows
+the newly-deleted items.
+
+
+Comment #5:
+
+The description of Previous says:
+
+BEGIN QUOTE:
+
+If Position equals No_Element or designates the first element of the
+container,
+then Previous returns the value No_Element. Otherwise, it returns a cursor
+that
+designates the element with index (To_Index (Position) - 1) in the same
+vector
+as Position.
+
+END QUOTE:
+
+Small formatting point: in the desc of Next, you didn't put the index
+expression in parens.
+
 ****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, November 15, 2005  9:38 PM
+
+> I'm having trouble parsing the first sentence, in conjunction with the 2nd
+> bullet.
+> 
+> The first sentence says that some operations do not replace elements.  But
+> the 2nd bullet says that Replace_Element (which does replace elements) is
+> one of the operations that don't replace elements...
 
-From: Matthew Heaney
-Sent: Friday, June 17, 2005  9:31 AM
+We struggled with this one.  This probably would benefit from
+dropping the first sentence, and simplifying it to:
 
+    A subprogram is said to "tamper with elements" of a vector
+    object V if: ...
+
+I think we included the first sentence and the
+"during such an operation" to restrict the definition
+to apply in a very narrow circumstance, but it seems it just
+made the whole thing more confusing.  The same simplification
+could be made to the definition of "tamper with cursors"
+I suspect.
+
+The point is that there are certain operations that can
+"call out" to user-supplied subprograms, and if we
+presume that they don't replace elements, then it is
+an error for them to "tamper with elements."
+
 ****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, November 15, 2005 11:50 PM
+
+Tucker writes:
+
+> We struggled with this one.  This probably would benefit from
+> dropping the first sentence, and simplifying it to:
+>
+>     A subprogram is said to "tamper with elements" of a vector
+>     object V if: ...
+>
+> I think we included the first sentence and the
+> "during such an operation" to restrict the definition
+> to apply in a very narrow circumstance, but it seems it just
+> made the whole thing more confusing.  The same simplification
+> could be made to the definition of "tamper with cursors"
+> I suspect.
+
+No, that's not the idea at all. It's simply to explain what these things are
+for; otherwise they just appear out of the blue in the text, and are just
+completely mysterious.
+
+To the extent that this text seems to restrict the applicability of these
+rules, it's wrong. But I don't think that there is any such restriction in
+practice.
+
+> The point is that there are certain operations that can
+> "call out" to user-supplied subprograms, and if we
+> presume that they don't replace elements, then it is
+> an error for them to "tamper with elements."
+
+Right, but if you drop the initial text, you've completely lost this point
+(because there is nothing about "calling out" or "presuming"; there is just
+this mysterious glob of text that has nothing to do with anything else near
+it (all of the uses are 3 [for tamper with elements] and 8 pages away).
+
+That text also is supposed to explain what it means to "tamper with
+elements" (element(s) are replaced) or "tamper with cursors" (elements are
+added, deleted, or shuffled around).
 
-From: Matthew Heaney
-Sent: Friday, June 17, 2005  9:31 AM
+I can believe that there is a better way to present that information, but
+just dropping the text doesn't help the readers any. (I suppose we can say
+that this is a Standard, and we don't care that no one can understand what
+this stuff is for. But that's not how the Ada standard was written.)
 
 ****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, November 15, 2005 11:46 PM
+
+> Here are a few comments on the vectors section of the latest AI-302 draft.
+
+The deadline for comments on Draft 14 was noon CST today (that is, 12 hours
+ago). Don't bother with any more; future comments will have to be submitted
+via WG9.
+
+> The first line of my copy of the draft says:
+>
+> !standard A.18 (00)   05-09-20  AI95-00302-03/15
+>
+> I got the draft here:
+>
+> http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-20302.TXT?rev=1.23
+>
+>
+> Comment #1:
+>
+> The draft says:
+>
+> BEGIN QUOTE:
+>
+> Some operations are assumed not to replace elements. During the execution
+> of such an operation, a subprogram is said to *tamper with elements* of a
+> vector object V if:
+>
+>    * it tampers with cursors of V; or
+>    * it replaces one or more elements of V, that is, it calls the
+>      Replace_Element, Reverse_Elements, or Swap procedures or the Sort or
+>      Merge procedures of an instance of Generic_Sorting with V as a
+> parameter.
+>
+> END QUOTE.
+>
+> I'm having trouble parsing the first sentence, in conjunction with the 2nd
+> bullet.
+>
+> The first sentence says that some operations do not replace elements.  But
+> the 2nd bullet says that Replace_Element (which does replace elements) is
+> one of the operations that don't replace elements.
+
+Certainly you're right that you're having trouble, because it doesn't say
+anything like that. It says that Replace_Element "tampers with elements"
+during the execution of the operation that *assumes* to avoid replacements.
+
+Tucker suggests just dropping all of the explanation. But we had it that way
+once, and it just doesn't work (at least, if we expect anyone other than
+implementers to understand this). Without the introduction, you just have
+this definition out of the blue, with no idea of what it means or why you
+care or what it might be used for. That would be OK in most Standards, I
+suppose, but not in Ada. These rules are rather unimportant in the grand
+scheme of things, and it's obnoxious to have to put them up front here where
+they interfere with understanding of things.
+
+Anyway, I'm open to suggestions, but I don't think Tucker's works. And you
+didn't make a suggestion (at this point, comments without suggested
+replacement wording are subject to be ignored).
+
+> Comment #2:
+>
+> The AARM Note in the description of Replace_Element says:
+>
+> BEGIN QUOTE:
+>
+> AARM Note: Replace_Element and Update_Element are the only ways that an
+> element
+> can change from empty to non-empty.
+>
+> END QUOTE.
+
+That's not what this note says. Read the AARM, not obsolete AIs.
+
+> Did the semantics change here? IIRC, it used to be the case that only
+> Replace_Element could be used to do that "reliably."  In the statement
+> above, you don't qualify the use of Update_Element for this purpose (to
+> change the empty state of an element), so I interpret that to mean that
+> Update_Element is now equivalent to Replace_Element.  Were the semantics
+> liberalized?  Has Update_Element really become portable?  (Or perhaps
+there
+> are other rules elsewhere in the language that handle the case of using
+> Update_Element to manipulate an empty element.)
+
+I'm not in the mood for 40 questions, and in any case, these questions are
+just stupid; it's plainly obvious that nothing has changed (including this
+note!!!).
+
+> Comment #3:
+>
+> The description of Insert says:
+>
+> BEGIN QUOTE:
+>
+> procedure Insert (Container : in out Vector;
+>                   Before    : in     Extended_Index;
+>                   New_Item  : in     Vector);
+>
+> ...If the current vector capacity is less than or equal to NL,
+> Reserve_Capacity (Container, NL) is called to increase the vector
+> capacity.
+>
+> END QUOTE.
+>
+>
+> Shouldn't the first part of that sentence say just "less than" instead of
+> "less than or equal"?
+
+Yes, I suppose. It's been that way forever (in all of the vector Inserts);
+do you know why?
+
+> Comment #4:
+...
+> I have already argued in a previous review that I don't like these
+> semantics.
+
+Yes, I gave you an extensive reply. We don't want "tricky" semantics for
+these routines, and setting parameters to point at random other elements is
+that.
+
+...
+> To buttress my argument, consider the behavior of Insert:
+>
+> procedure Insert (Container : in out Vector;
+>                   Before    : in     Cursor;
+>                   New_Item  : in     Vector;
+>                   Position  :    out Cursor);
+>
+> ... Position is set to To_Cursor (Container, T).
+>
+> END QUOTE.
+
+Note that the original Cursor and the new one are in different parameters.
+
+The operation you want would have a signature of:
+
+procedure Delete (Container : in out Vector;
+                  Position  : in out  Cursor;
+                  First_Undeleted_Item :    out Cursor;
+                  Count     : in     Count_Type := 1);
+
+(That is, the returned value would be separate than the value passed in.)
+It's too late to be adding such things.
+
+> Comment #5:
+>
+> The description of Previous says:
+>
+> BEGIN QUOTE:
+>
+> If Position equals No_Element or designates the first element of the container,
+> then Previous returns the value No_Element. Otherwise, it returns a cursor that
+> designates the element with index (To_Index (Position) - 1) in the same vector
+> as Position.
+>
+> END QUOTE:
+>
+> Small formatting point: in the desc of Next, you didn't put the index
+> expression in parens.
 
-From: Matthew Heaney
-Sent: Friday, June 17, 2005  9:31 AM
+OK, made them match.
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent