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

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

--- ai05s/ai05-0031-1.txt	2007/04/11 00:57:10	1.2
+++ ai05s/ai05-0031-1.txt	2010/02/12 05:24:21	1.3
@@ -1,4 +1,4 @@
-!standard A.4.3(16)                                       06-12-14    AI05-0031-1/00
+!standard A.4.3(16)                                10-02-11    AI05-0031-1/01
 !standard A.4.3(67)
 !standard A.4.3(68/1)
 !standard A.4.4(51)
@@ -16,20 +16,104 @@
 
 !problem
 
-** See mail **
+Find_Token in Ada.Strings.Fixed, Ada.Strings.Unbounded and Ada.Strings.Bounded
+has no version with a From index. A From index (the index where to start
+looking) has been added into the Index routines in those same packages.
 
+It is important to be able to start in the middle of a long string when
+iterating to find multiple tokens.
+
 !proposal
 
-[Add a From parameter to Find_Token in all of the predefined string packages]
+Add a From parameter to Find_Token in all of the predefined string packages.
 
 !wording
+
+Add before A.4.3(16):
+
+   procedure Find_Token (Source : in String;
+                         Set    : in Maps.Character_Set;
+                         From   : in Positive;
+                         Test   : in Membership;
+                         First  : out Positive;
+                         Last   : out Natural);
+
+[Editor's Note: The From parameter in the third Index is placed before the
+Test : in Membership parameter. I'm not sure why, but I put it in the same
+place here, to be consistent. The worst thing would be to have it in all
+different places.]
+
+Add before A.4.3(67):
+
+   procedure Find_Token (Source : in String;
+                         Set    : in Maps.Character_Set;
+                         From   : in Positive;
+                         Test   : in Membership;
+                         First  : out Positive;
+                         Last   : out Natural);
+
+
+Find_Token returns in First and Last the indices of the beginning and end of the
+first slice of Source where First >= From, all of the elements of the slice
+satisfy the Test condition, and such that the elements (if any) immediately
+before and after the slice do not satisfy the Test condition. If no such slice
+exists, then the value returned for Last is zero, and the value returned for
+First is From; however, if From is not in Positive then Constraint_Error is
+raised.
+
+Replace A.4.3(68/1) by:
 
-(** TBD **)
+Equivalent to Find_Token (Source, Set, Source'First, Test, First, Last).
 
+Add before A.4.4(51):
+
+   procedure Find_Token (Source : in Bounded_String;
+                         Set    : in Maps.Character_Set;
+                         From   : in Positive;
+                         Test   : in Membership;
+                         First  : out Positive;
+                         Last   : out Natural);
+
+Add before A.4.5(46):
+
+   procedure Find_Token (Source : in Unbounded_String;
+                         Set    : in Maps.Character_Set;
+                         From   : in Positive;
+                         Test   : in Membership;
+                         First  : out Positive;
+                         Last   : out Natural);
+
 !discussion
 
-** TBD **
+This is a consistency change; all of the searching routines in the Strings
+packages should have similar capabilities. Note we add the new routines
+before the old ones to be consistent with how that was done for function
+Index.
+
+** Possible bug **
+
+Consider the following:
+
+Source(1..7) := "1234567";
+Set := "345";
+Find_Token (Source, Set, From => 3, Test => Inside, First => First, Last => Last);
+-- After this call, First = 3, Last = 5.
+Find_Token (Source, Set, From => 4, Test => Inside, First => First, Last => Last);
+-- After this call, First = 4, Last = 0.
+
+The latter result requires some explanation. The wording requires three things
+about a slice: First >= From, all the elements in the slice satisfy the test,
+*and* the elements immediately before and after the slice do not satisfy the
+test condition. The slice 3 .. 5 fails the first test, and the slice 4 .. 5
+fails that last test (because the element at From-1 *does* satisfy the test).
+
+I considered an alternative wording where the string would act like was
+truncated at From. That however has the effect of possibly splitting tokens,
+which seems weird. But the defined semantics is weird, too. This seems like a
+possible reason why we didn't add From to this routine in the first place.
 
+** Decide on proper semantics **
+
 !example
 
 !ACATS test
@@ -94,36 +178,36 @@
 it.  I think you're right, this is an omission.
 
 > The only version is:
-> 
+>
 >    procedure Find_Token (Source : in Unbounded_String;
 >                          Set    : in Maps.Character_Set;
 >                          Test   : in Membership;
 >                          First  : out Positive;
 >                          Last   : out Natural);
-> 
+>
 > I would like to propose this :
-> 
+>
 >    procedure Find_Token (Source : in Unbounded_String;
 >                          Set    : in Maps.Character_Set;
 >                          Test   : in Membership;
 >                          From   : in Positive;
 >                          First  : out Positive;
 >                          Last   : out Natural);
-> 
+>
 > >From being here the starting position to look for the given token. An
 > alternate solution could be to use First:
-> 
+>
 >    procedure Find_Token (Source : in Unbounded_String;
 >                          Set    : in Maps.Character_Set;
 >                          Test   : in Membership;
 >                          First  : in out Positive;
 >                          Last   : out Natural);
-> 
-> 
+>
+>
 > In this case the First parameter is changed to mode "in out", the
 > initial value being the starting position to look for the given token.
 > This last solution looks better to me.
-> 
+>
 > Thoughts ?
 
 I definitely like the first solution (separate From and First
@@ -341,7 +425,7 @@
 Sent: Wednesday, November 8, 2006  3:12 PM
 
 > How could we define "string literals" (or aggregates) for private types?
-> 
+>
 > What kind of literals are envisaged after all?
 
 The idea is that the programmer provides a function that converts from the
@@ -380,7 +464,7 @@
 Sent: Wednesday, November 8, 2006  9:27 PM
 
 > How could we define "string literals" (or aggregates) for private types?
-> 
+>
 > What kind of literals are envisaged after all?
 
 and Robert A. Duff replies:
@@ -544,8 +628,8 @@
 From: Pascal Leroy
 Sent: Thursday, November 9, 2006  2:07 AM
 
-> It's a judgement call.  I have no strong opinion one way or 
-> 'tother here. I don't think the possibility of name conflicts 
+> It's a judgement call.  I have no strong opinion one way or
+> 'tother here. I don't think the possibility of name conflicts
 > should absolutely rule out additions to predefined packages.
 
 I am not too concerned about name conflicts (I believe that they are
@@ -636,15 +720,69 @@
 From: Pascal Leroy
 Sent: Friday, November 10, 2006  1:42 AM
 
-> Vendors don't release 
-> new versions of compilers for every 10 minute change that 
-> comes from the ARG! Depending on the vendor, compiler 
-> releases require a lot of QA testing, documentation work, and 
-> the like. Often, release cycles are over a year or more long. 
+> Vendors don't release
+> new versions of compilers for every 10 minute change that
+> comes from the ARG! Depending on the vendor, compiler
+> releases require a lot of QA testing, documentation work, and
+> the like. Often, release cycles are over a year or more long.
 
 Not to mention that, once a release is out, users don't rush to adopt it.
 We still have users happily using a version that we released in 2000, and
 they won't move to more recent stuff for fear of destabilizing their
 environment.  These big projects have a huge inertia.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, February 11, 2010  11:18 PM
+
+One of my action items was to create wording for the additional Find_Token
+routine that we think should be added for consistency.
+
+Here's what I came up with:
+
+   procedure Find_Token (Source : in String;
+                         Set    : in Maps.Character_Set;
+                         From   : in Positive;
+                         Test   : in Membership;
+                         First  : out Positive;
+                         Last   : out Natural);
+
+Find_Token returns in First and Last the indices of the beginning and end of the
+first slice of Source where First >= From, all of the elements of the slice
+satisfy the Test condition, and such that the elements (if any) immediately
+before and after the slice do not satisfy the Test condition. If no such slice
+exists, then the value returned for Last is zero, and the value returned for
+First is From; however, if From is not in Positive then Constraint_Error is
+raised.
+
+Unfortunately, it's not clear this is what is intended. What is supposed to
+happen if From is in the middle of a token? Consider:
+
+Source(1..7) := "  345  ";
+Set := " ";
+Find_Token (Source, Set, From => 3, Test => Outside, First => First, Last => Last);
+-- After this call, First = 3, Last = 5.
+Find_Token (Source, Set, From => 4, Test => Outside, First => First, Last => Last);
+-- After this call, First = 4, Last = 0.
+
+The latter result requires some explanation. The wording requires three things
+about a slice: First >= From, all the elements in the slice satisfy the test,
+*and* the elements immediately before and after the slice do not satisfy the
+test condition. The slice 3 .. 5 fails the first test, and the slice 4 .. 5
+fails that last test (because the element at From-1 *does* satisfy the test).
+
+I considered an alternative wording where the string would act like was
+truncated at From. That however has the effect of possibly splitting tokens,
+which seems weird. But the defined semantics is weird, too. This seems like a
+possible reason why we didn't add From to this routine in the first place.
+
+I have no idea which of these semantics is right. Index doesn't care what
+precedes From, so it is no help. Returning "45" from the string "  345  " seems
+wrong. OTOH, the similar call: Find_Token (Source(4..7), Set, Test => Outside,
+First => First, Last => Last); does return First = 4, Last = 5.
+
+Thoughts? And if you want the alternative wording, how would you word it? I had
+enough trouble getting the above wording to make sense.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent