CVS difference for ais/ai-00301.txt

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

--- ais/ai-00301.txt	2002/10/01 03:08:54	1.6
+++ ais/ai-00301.txt	2003/09/19 01:31:56	1.7
@@ -1,4 +1,4 @@
-!standard A.4.5                                     02-09-30  AI95-00301/04
+!standard A.4.5                                     03-09-18  AI95-00301/05
 !class amendment 02-06-12
 !status work item 02-06-12
 !status received 02-06-12
@@ -15,18 +15,26 @@
 
 !problem
 
-The interface defined for Ada.Strings.Unbounded contains several instances
-where the Unbounded_String abstraction is incomplete. For instance, the Insert,
-Overwrite, and Replace_Slice routines do not include a version in which
-the new portion is an Unbounded_String. Thus, it is necessary to leave the
+The package Ada.Strings.Unbounded contains an incomplete set of facilities.
+Many of these omissions mean that it is necessary to convert back and forth
+to String (thus leaving the Unbounded_String abstraction) in order to
+handle them. In some cases, the operations have to be done with
+Ada.Strings.Fixed.
+
+For instance, a commonly encountered problem is the need to find all of the
+occurrences of a pattern in a string. The Index function always searches the
+entire string. This is not a major problem for a String, as searching the
+appropriate slice is easy. However, for an Unbounded_String, the only practical
+solution is to convert the Unbounded_String to a String, and using
+Ada.Strings.Fixed to do the operation.
+
+Many operations in Ada.Strings.Unbounded take only String parameters or results.
+For instance, the Insert, Overwrite, and Replace_Slice routines do not include
+a version in which the new portion is an Unbounded_String. Similarly, Slice
+returns only a String. Thus, it is necessary to leave the
 Unbounded_String abstraction (by converting to String) in order to use these
-operations. This extra conversion also carries an unnecessary time and storage
-overhead.
+operations. This extra conversion is very verbose.
 
-A similar problem occurs when a slice of an Unbounded_String is needed.
-The Slice function returns a String, which is outside of the Unbounded_String
-abstraction.
-
 Another problem is that Unbounded_Strings typically are implemented as a
 controlled type. That means that an assignment of an Unbounded_String has
 substantial overhead in the form of calls to Finalize and Adjust, and
@@ -37,13 +45,6 @@
 overhead. A procedure version of To_Unbounded_String would avoid this
 problem.
 
-A commonly encountered problem is the need to find all of the occurrences
-of a pattern in a string. The Index function always searches the entire
-string. This is not a major problem for a String, as searching the appropriate
-slice is easy. However, for an Unbounded_String, the only practical solution
-is to convert the Unbounded_String to a String, again breaking the abstraction.
-A variant with a starting index as a parameter would be very useful.
-
 And finally, I/O operations with Unbounded_Strings as parameters are not
 provided. These are commonly needed, and (in the case of Get_Line) are not
 trivial to write. An child package similar to the ones provided for Complex
@@ -101,24 +102,50 @@
 in these, the Source parameter is a Bounded_String and Unbounded_String,
 respectively.
 
+
+The following operations are added to package Ada.Strings.Bounded:
 
-The following operation is added to package Ada.Strings.Bounded:
+   function "+" (Source : Bounded_String) return String;
+   --  Identical in effect to To_String (Source);
 
+   function "+" (Source : String) return Bounded_String;
+   --  Identical in effect to To_Bounded_String (Source, Error);
+
    procedure Set_Bounded_String
      (Target :    out Bounded_String;
-      Str    : in     String);
-   --  Identical in effect to Target := To_Bounded_String (Str);
-
-The following operation is added to package Ada.Strings.Unbounded:
+      Source : in     String);
+      Drop   : in     Truncation := Error);
+   --  Identical in effect to Target := To_Bounded_String (Source, Drop);
 
-   procedure Set_Unbounded_String
-     (Target :    out Unbounded_String;
-      Str    : in     String);
-   --  Identical in effect to Target := To_Unbounded_String (Str);
+   function Bounded_Slice
+     (Source : in Unbounded_String;
+      Low    : in Positive;
+      High   : in Natural;
+      Drop   : in     Truncation := Error)
+     return Unbounded_String;
+   --  Identical to To_Bounded_String (Slice (Source, Low, High), Drop);
 
+   procedure Bounded_Slice
+     (Source : in     Unbounded_String;
+      Target :    out Unbounded_String;
+      Low    : in     Positive;
+      High   : in     Natural;
+      Drop   : in     Truncation := Error)
+   --  Identical to Target := To_Bounded_String (Slice (Source, Low, High), Drop);
 
 The following operations are added to package Ada.Strings.Unbounded:
 
+   function "+" (Source : Unbounded_String) return String;
+   --  Identical in effect to To_String (Source);
+
+   function "+" (Source : String) return Unbounded_String;
+   --  Identical in effect to To_Unbounded_String (Source);
+
+   procedure Set_Unbounded_String
+     (Target :    out Unbounded_String;
+      Source : in     String);
+   --  Identical in effect to Target := To_Unbounded_String (Source);
+
    function Unbounded_Slice
      (Source : in Unbounded_String;
       Low    : in Positive;
@@ -133,55 +160,7 @@
       High   : in     Natural);
    --  Identical to Target := To_Unbounded_String (Slice (Source, Low, High));
 
-   function  Replace_Slice
-     (Source : in Unbounded_String;
-      Low    : in Positive;
-      High   : in Natural;
-      By     : in Unbounded_String)
-     return Unbounded_String;
-   --  Identical in effect to
-   --    Replace_Slice (Source, Low, High, To_String (By));
-
-   procedure Replace_Slice
-     (Source : in out Unbounded_String;
-      Low    : in     Positive;
-      High   : in     Natural;
-      By     : in     Unbounded_String);
-   --  Identical in effect to
-   --    Replace_Slice (Source, Low, High, To_String (By));
-
-   function Insert
-     (Source   : in Unbounded_String;
-      Before   : in Positive;
-      New_Item : in Unbounded_String)
-     return Unbounded_String;
-   --  Identical in effect to Insert (Source, Before, To_String (New_Item));
-
-   procedure Insert
-     (Source   : in out Unbounded_String;
-      Before   : in     Positive;
-      New_Item : in     Unbounded_String);
-   --  Identical in effect to Insert (Source, Before, To_String (New_Item));
-
-   function Overwrite
-     (Source   : in Unbounded_String;
-      Position : in Positive;
-      New_Item : in Unbounded_String)
-     return Unbounded_String;
-   --  Identical in effect to
-   --    Overwrite (Source, Position, To_String (New_Item));
 
-   procedure Overwrite
-     (Source   : in out Unbounded_String;
-      Position : in     Positive;
-      New_Item : in     Unbounded_String);
-   --  Identical in effect to
-   --    Overwrite (Source, Position, To_String (New_Item));
-
-Similar operations are added to Ada.Strings.Bounded, with the difference that
-Unbounded_Slice is named Bounded_Slice.
-
-
 The following child package is defined:
 
 with Ada.Strings.Unbounded;
@@ -250,21 +229,27 @@
 
 !discussion
 
+Ada.Strings.Unbounded was not really intended to be a complete abstraction.
+Rather, it was designed to provide a convinient storage representation
+mechanism for strings. Even so, it is a bad idea to have to use multiple
+string packages in a single expression, and many common operations require
+that.
+
 The new operations added to Ada.Strings.Fixed, Ada.Strings.Bounded, and
 Ada.Strings.Unbounded could potentially cause new ambiguities in programs if
-there is a use clause for the string package. However, this is unlikely,
-and no programs change meaning (any incompatibilities cause compile-time
-errors).
-
-If the compatibility issues are considered to be significant enough, then
-these new routines could be added as child packages. Such a child package
-would not cause compatibility problems; however, it would look like an ugly
-add-on. And, choosing a name is difficult. Some of the names proposed
+there is a use clause for the string package. However, this is unlikely (as the
+new routines have relatively lengthy names), and no programs change meaning
+(any incompatibilities cause compile-time errors).
+
+If the compatibility issues were considered to be significant enough, then
+these new routines could have been added as child packages. Such a child
+package would not cause compatibility problems; however, it would look like an
+ugly add-on. And, choosing a name is difficult. Some of the names proposed
 include Ada.Strings.Unbounded.Additional_Operations,
 Ada.Strings.Unbounded.Enhancements, Ada.Strings.Unbounded.More,
 Ada.Strings.Unbounded.Unbounded_Operations, or
-Ada.Strings.Unbounded.Stuff_that_should_have_been_here_all_along. (OK, the
-last is a joke.) Thus, we did not follow this alternative.
+Ada.Strings.Unbounded.Stuff_that_should_have_been_here_all_along. (OK, the last
+is a joke.) Thus, we did not follow this alternative.
 
 
 An earlier proposal for the Index functions was to add a defaulted From
@@ -749,7 +734,7 @@
 --                                                                          --
 --                                 S p e c                                  --
 --                                                                          --
---    $Revision: 1.6 $                              --
+--                            $Revision: 1.7 $                              --
 --                                                                          --
 --          Copyright (C) 1992-1998, Free Software Foundation, Inc.         --
 --                                                                          --
@@ -1142,7 +1127,9 @@
 > can't you just work with slices directly? I thought the Index
 > operations were needed only for bounded and unbounded strings.
 
-This is simply for consistency. Virtually every function in Ada.Strings.Unbounded has a similar function in Ada.Strings.Fixed. It would be odd if we didn't carry that through for the new Index functionality.
+This is simply for consistency. Virtually every function in
+Ada.Strings.Unbounded has a similar function in Ada.Strings.Fixed. It would be
+odd if we didn't carry that through for the new Index functionality.
 
 > Furthermore, I think it should be specified that these new
 > Index operations propagate Ada.Strings.Index_Error if
@@ -1153,15 +1140,19 @@
 > Also, you write that there'd be "similar operations" for bounded
 > and unbounded strings. What does that mean?
 
-Similar in the same way that these four are defined to the existing ones (just adding a From parameter).
+Similar in the same way that these four are defined to the existing ones (just
+adding a From parameter).
 
 > Do you plan to also add versions of the existing
 > Index functions (without the From parameter) where the Pattern
 > would be of type (Un)Bounded_String?
 
-No. "Patterns" are rather special; they typically aren't manipulated at the same time as the items being searched. So I didn't include Index and Count routines with Unbounded_String patterns.
+No. "Patterns" are rather special; they typically aren't manipulated at the
+same time as the items being searched. So I didn't include Index and Count
+routines with Unbounded_String patterns.
 
-That could be done (I wouldn't object strongly), but I worry if the compatibility concerns mentioned by Robert would be severe in this case.
+That could be done (I wouldn't object strongly), but I worry if the
+compatibility concerns mentioned by Robert would be severe in this case.
 
 > In procedure Slice, I'd change the order of parameters to
 >
@@ -1174,14 +1165,18 @@
 > (specify the whole slice before passing the target, similar
 > to Replace_Slice.)
 
-Huh? The Target (well, it's called "Source", but it's where the result is written) is the first parameter of Replace_Slice.
+Huh? The Target (well, it's called "Source", but it's where the result is
+written) is the first parameter of Replace_Slice.
 
 > Why is parameter Target in To_Bounded_String and To_Unbounded_String
 > of mode "in out" instead of "out"? And why is parameter Item in
 > procedure Ada.Text_IO.Unbounded_IO.Get_Line of mode "in out" and
 > not just "out"? In procedure Slice, Target is of mode "out"...
 
-Sloppy work on my part. My personal programming style never uses "out" parameters on composite types, as they are always default-initialized and that initialization must not be lost. (Practically, "out" and "in out" are the same for composite types anyway
.) But that's wrong for this package.
+Sloppy work on my part. My personal programming style never uses "out"
+parameters on composite types, as they are always default-initialized and that
+initialization must not be lost. (Practically, "out" and "in out" are the same
+for composite types anyway.) But that's wrong for this package.
 
 > Other than that, it looks good to me, although I do not understand
 > why the ARG did not retain the originally proposed operations where
@@ -1191,12 +1186,24 @@
 > and the interface would then be really complete. As it is, one still
 > would have to go through intermediary explicit representations of
 > the slices.
-
-Most of the ARG's concern was with the broken abstraction (the fact that you have to explicitly convert to String before you can do much useful). Performance issues were secondary (Unbounded strings are pretty expensive in general; you won't use them much
 if performance is critical). The main reason for the procedure versions of functions is simply that most of the functions already have procedure versions; they all (except for the operator systems) should have them to be consistent.
-
-However (in my opinion), your proposed slice operations exist only to improve efficiency. They're complex (at least in appearance), they muddy the abstraction, and they add a lot of weight to the interface - mostly on little used subprograms. No one spoke
 in favor of them; the general reaction was "UGH".
 
-We all have ideas that we think are great that get killed for one reason or another. It's just part of the process - it's rare that a final feature looks much like the initial proposal.
+Most of the ARG's concern was with the broken abstraction (the fact that you
+have to explicitly convert to String before you can do much useful).
+Performance issues were secondary (Unbounded strings are pretty expensive in
+general; you won't use them much if performance is critical). The main reason
+for the procedure versions of functions is simply that most of the functions
+already have procedure versions; they all (except for the operator systems)
+should have them to be consistent.
+
+However (in my opinion), your proposed slice operations exist only to improve
+efficiency. They're complex (at least in appearance), they muddy the
+abstraction, and they add a lot of weight to the interface - mostly on little
+used subprograms. No one spoke in favor of them; the general reaction was
+"UGH".
+
+We all have ideas that we think are great that get killed for one reason or
+another. It's just part of the process - it's rare that a final feature looks
+much like the initial proposal.
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent