CVS difference for ais/ai-00301.txt

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

--- ais/ai-00301.txt	2002/08/24 03:54:24	1.3
+++ ais/ai-00301.txt	2002/08/29 03:33:21	1.4
@@ -1,4 +1,4 @@
-!standard A.4.5                                     02-08-23  AI95-00301/02
+!standard A.4.5                                     02-08-26  AI95-00301/03
 !class amendment 02-06-12
 !status work item 02-06-12
 !status received 02-06-12
@@ -63,6 +63,7 @@
     --    Index (Source(From..Source'Last), Pattern, Going, Mapping)
     -- Otherwise, this is equivalent to
     --    Index (Source(Source'First..From), Pattern, Going, Mapping)
+    -- Index_Error is propogated if From is not in Source'range.
 
     function Index (Source : in String;
                     Pattern : in String;
@@ -73,6 +74,7 @@
     --    Index (Source(From..Source'Last), Pattern, Going, Mapping)
     -- Otherwise, this is equivalent to
     --    Index (Source(Source'First..From), Pattern, Going, Mapping)
+    -- Index_Error is propogated if From is not in Source'range.
 
     function Index (Source : in String;
                     Set : in Maps.Character_Set;
@@ -83,6 +85,7 @@
     --    Index (Source(From..Source'Last), Set, Test, Going)
     -- Otherwise, this is equivalent to
     --    Index (Source(Source'First..From), Set, Test, Going)
+    -- Index_Error is propogated if From is not in Source'range.
 
     function Index_Non_Blank (Source : in String;
                               From : in Positive;
@@ -91,6 +94,7 @@
     --    Index_Non_Blank (Source(From..Source'Last), Going)
     -- Otherwise, this is equivalent to
     --    Index_Non_Blank (Source(Source'First..From), Going)
+    -- Index_Error is propogated if From is not in Source'range.
 
 
 Similar functions are added to Ada.Strings.Bounded and Ada.Strings.Unbounded.
@@ -99,14 +103,14 @@
 The following operation is added to package Ada.Strings.Bounded:
 
    procedure To_Bounded_String
-     (Target : in out 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:
 
    procedure To_Unbounded_String
-     (Target : in out Unbounded_String;
+     (Target :    out Unbounded_String;
       Str    : in     String);
    --  Identical in effect to Target := To_Unbounded_String (Str);
 
@@ -220,11 +224,11 @@
   --  Identical to Get_Line (Ada.Text_IO.Current_Input);
 
   procedure Get_Line
-    (File : in File_Type; Item : in out Ada.Strings.Unbounded.Unbounded_String);
+    (File : in File_Type; Item : out Ada.Strings.Unbounded.Unbounded_String);
   -- Equivalent to Item := Get_Line (File);
 
   procedure Get_Line
-    (Item : in out Ada.Strings.Unbounded.Unbounded_String);
+    (Item : out Ada.Strings.Unbounded.Unbounded_String);
   -- Equivalent to Item := Get_Line;
 
 end Ada.Text_IO.Unbounded_IO;
@@ -285,7 +289,7 @@
 Ada.Text_IO.Unbounded_IO.Get_Line can be implemented as follows:
 
      procedure Get_Line (File : in File_Type;
-         Item : in out Ada.Strings.Unbounded.Unbounded_String) is
+         Item : out Ada.Strings.Unbounded.Unbounded_String) is
          Buffer : String (1 .. 80);
          Last : Natural;
      begin
@@ -737,7 +741,7 @@
 --                                                                          --
 --                                 S p e c                                  --
 --                                                                          --
---    $Revision: 1.3 $                              --
+--                            $Revision: 1.4 $                              --
 --                                                                          --
 --          Copyright (C) 1992-1998, Free Software Foundation, Inc.         --
 --                                                                          --
@@ -876,4 +880,493 @@
 
 ****************************************************************
 
+From: Nick Roberts
+Sent: Saturday, August 24, 2002 5:44 PM
+
+I disagree with the argument against using the name
+"Set_Unbounded_String" instead of "To_Unbounded_String" (for the
+new procedures which analogise the "To_Unbounded_String"
+functions).
+
+The argument given in AI-301 (v1.3) is that using "Set_" would
+risk name collisions with existing code. However, I do not see
+why this name would carry any greater risk, in general, than
+"To_". Thus I would urge the use of the less confusing "Set_".
+
+I'm otherwise enthusiastic about the extra facilities.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, August 24, 2002  6:20 PM
+
+But the proposed name was "Set", not "Set_Unbounded_String". Try the argument
+again with that name...
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Saturday, August 24, 2002  9:11 PM
+
+I consider this spec awful. It is highly non-upwards incompatible. I don'
+t think we would consider implementing something that was upwards
+incompatible in this way.
+
+Take for example, Slice which now can return either a string or
+unbounded string.
+
+Well I have all over the place overloaded functions that take either
+a string or unbounded string. The following is a model of the sort
+of program that will get blown up:
+
+with Ada.Strings.Unbounded; use Ada.Strings.Unbounded;
+procedure Q is
+   procedure Pstr (S : String) is begin null; end;
+   procedure Pstr (S : Unbounded_String) is begin null; end;
+
+   A : Unbounded_String;
+
+begin
+   Pstr (Slice (A, 1, 3));
+end;
+
+Sure, things can be mended. But mending things in a big system is not as
+easy as technical folks would suppose.
+
+I am strongly opposed to *ANY* non-upwards compatible changes, especially
+when they are gratuitous as in this case.
+
+Robert Dewar
+
+The AI says
+
+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).
+
+How did anyone decide this is unlikely?
+
+The fact that no programs change meaning is thin comfort to people who have
+to make changes to programs that they are not necessarily familiar with and
+which are under strict configuration control (meaning that the process for
+making ANY changes can be heavy).
+
+To me, the ONLY acceptable way of adding functionality to existing packages
+is to add child packages. Yes, it is a bit kludgy, but elegance takes a
+back seat to compatibility requirements at this stage.
+
+This makes me worry a lot. I hope this unacceptably casual view of
+incompatibility is not showing up in other AI's. If it is, then I
+think it makes it likely that the entire set of extensions will get
+ignored.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, August 26, 2002  6:21 PM
+
+Yes, this example demonstrates the problem with Ada.Strings.Unbounded.
+
+The most likely reason that PStr is overloaded in the first place is because
+Slice didn't return an Unbounded string. So both versions were necessary to
+avoid code explosion.
+
+So your point is essentially that we can't fix the broken abstraction of
+Ada.Strings.Unbounded because it would break the workarounds to the broken
+abstraction of Ada.Strings.Unbounded. Perhaps you are right (this is only an
+early draft of an AI in any case, and it will need to be discussed again).
+That does seem to be a sad state of affairs if true.
+
+In that case, my preference would be to dump Ada.Strings.Unbounded
+altogether and start over (which would be compatible, I believe). Trying to
+fix this with a child package would only make the embarassment of a broken
+abstraction permanent. (If you think that Ada other than GNAT is on its
+deathbed anyway, perhaps it doesn't matter.)
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, August 26, 2002  9:06 PM
+
+>
+> In that case, my preference would be to dump Ada.Strings.Unbounded
+> altogether and start over (which would be compatible, I believe). Trying to
+> fix this with a child package would only make the embarassment of a broken
+> abstraction permanent. (If you think that Ada other than GNAT is on its
+> deathbed anyway, perhaps it doesn't matter.)
+
+Actually Ada is alive and well, and we have plenty of competition :-)
+
+I certainly would not "dump" Ada.Strings.Unbounded, that would be even more
+incompatible. If you really think it is worth creating another slightly
+different abstraction, go ahead. It seems like a waste of time to me. There
+are more important fish to fry.
+
+> > procedure Q is
+> >    procedure Pstr (S : String) is begin null; end;
+> >    procedure Pstr (S : Unbounded_String) is begin null; end;
+> >
+> >    A : Unbounded_String;
+> >
+> > begin
+> >    Pstr (Slice (A, 1, 3));
+> > end;
+>
+> Yes, this example demonstrates the problem with Ada.Strings.Unbounded.
+>
+> The most likely reason that PStr is overloaded in the first place is because
+> Slice didn't return an Unbounded string. So both versions were necessary to
+> avoid code explosion.
+
+Nope, the reason that Pstr operates on String's and unbounded_strings is that
+I have strings and unbounded strings in my application (and that will be trye
+whatever you do to "improve" unbounded_string) and I want Pstr to be easily
+applied to either.
+
+Right now, the Unbounded_String abstraction is friendly to this approach.
+In addition, imagine what a mess you get with trying to concatenate slices
+if you make the change to Slice.
+
+Unbounded_String is not nearly broken enough to be worth considering non
+upwards-compatible fixes.
+
+I don't think the abstraction is broken, on the contrary in some respects I
+think you are trying to break it!
+
+Please, let's not even consider seriously non-upwards compatible changes. They
+will simply get ignored at this stage, and rightly so.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, August 26, 2002  9:41 PM
+
+> I don't think the abstraction is broken, on the contrary in some respects I
+> think you are trying to break it!
+
+Please explain this.
+
+I think that it should be possible to pick a single string abstraction and
+stick with it without having to switch to another. Ada.Strings.Unbounded falls
+far short of this, many common operations force switching to regular strings
+and Ada.Strings.Fixed. Very few operations allow any sort of combination or
+operations purely on unbounded strings. That so true that Jean-Pierre Rosen
+says that Ada.Strings.Unbounded is only good for storing strings. But if that
+is true, why are all of those other operations there?
+
+The only way to fix that is to add operations that can combine two unbounded
+strings. Otherwise, the package is rather an embarrassment, as it is a lousy
+example of an abstraction.
+
+In my spam scanner, I tried to use Ada.Strings.Unbounded consistently with the
+idea of showing Ada novices that it isn't any harder to use Ada than other
+languages. Bad plan; I had to pull the strings out into Strings repeatedly to
+search them, to do replacements, and other operations. Indeed, hardly anything
+could be accomplished without converting to String - which is very verbose. If
+I had realized that would be the case, I wouldn't have bothered with unbounded
+string at all - the memory management would have been fairly simple.
+
+Anyway, I have to agree that there are more important things to do. But it
+seems unlikely to me that most of those would not meet your 'perfect
+compatibility' requirement.
+
+****************************************************************
+
+From: Thomas Wolf
+Sent: Monday, August 26, 2002  7:47 AM
+
+I note that the proposal now includes new Index functions for
+Ada.Strings.Fixed. Are these needed? If you have fixed strings,
+can't you just work with slices directly? I thought the Index
+operations were needed only for bounded and unbounded strings.
+
+Furthermore, I think it should be specified that these new
+Index operations propagate Ada.Strings.Index_Error if
+From > Length (Source).
+
+Also, you write that there'd be "similar operations" for bounded
+and unbounded strings. What does that mean? What's the type of
+parameter Pattern? String or (Un)Bounded_String? Or are there to
+be two versions of each Index operation, one with Pattern of type
+String, and one with Pattern of type (Un)Bounded_String?
+
+If the latter, 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?
+
+If not the latter, why would there be only one, but not the other
+variant?
+
+In procedure Slice, I'd change the order of parameters to
+
+procedure Slice
+  (Source : in     Unbounded_String;
+   Low    : in     Positive;
+   High   : in     Natural;
+   Target :    out Unbounded_String);
+
+(specify the whole slice before passing the target, similar
+to 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"...
+
+Other than that, it looks good to me, although I do not understand
+why the ARG did not retain the originally proposed operations where
+the second parameter would be a slice of an (Un)Bounded_String,
+specified by the string and a low and a high index. Ok, that would
+add quite a few additional variants to the interface, but that's all,
+and the interface would then be really complete. As it is, one still
+would have to go through intermediary explicit representations of
+the slices.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, August 26, 2002  7:25 PM
+
+> I note that the proposal now includes new Index functions for
+> Ada.Strings.Fixed. Are these needed? If you have fixed strings,
+> 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.
+
+> Furthermore, I think it should be specified that these new
+> Index operations propagate Ada.Strings.Index_Error if
+> From > Length (Source).
+
+Yes, of course.
+
+> 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).
+
+> 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.
+
+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
+>
+> procedure Slice
+>   (Source : in     Unbounded_String;
+>    Low    : in     Positive;
+>    High   : in     Natural;
+>    Target :    out Unbounded_String);
+>
+> (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.
+
+> 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.
+
+> Other than that, it looks good to me, although I do not understand
+> why the ARG did not retain the originally proposed operations where
+> the second parameter would be a slice of an (Un)Bounded_String,
+> specified by the string and a low and a high index. Ok, that would
+> add quite a few additional variants to the interface, but that's all,
+> 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.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, August 26, 2002  10:30 PM
+
+I use unbounded strings extensively in all my SPITBOL like programs using
+g-spipat, and those programs work just fine.
+
+They definitely will *NOT* work fine if you make the changes you are planning.
+
+Once again, this is not nearly broken enough to even consider non-upwards
+compatible changes.
+
+We did not allow non-UC changes in Ada 95 except with VERY good justification,
+which certainly does not apply here.
+
+Data point: Not one of our customers ever asked questions about these aspects
+of US, or complained, and believe me, they ask plenty of questions and make
+plenty of complaints about the language in other respects.
+
+The fact that someone decides something is broken is not enough reason to go
+pestering it. Please point to a major user of Ada for whom this is an important
+issue.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, August 27, 2002  9:21 AM
+
+This proposal did not come from me, I'm just trying to write it up. I don't
+know the original proposer, so I can't say what perspective he has.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Tuesday, August 27, 2002  3:20 AM
+
+I find Robert's argument compelling.  While I am not adamantly opposed to
+non-upward compatible changes, I think the above example is something we
+want to avoid, as it seems like a perfectly legitimate programming style.
+It's one thing to add a new subprogram named Mess_With_Unbounded_String to a
+package spec (where incompatibilities can only come from use clause
+collisions, and are probably rare if the name is sufficiently convoluted).
+It's an entirely different thing to add a new overload with parameter/result
+types that are likely to be used in conjunction with unbounded strings.
+
+Interestingly enough, I don't remember agreeing to changes regarding slices
+during the last meeting.  That may have been overheating, but then I see in
+the minutes that "there is not much interest in the slice version of the
+operations that were proposed".  The ARG in the other hand was in favor of
+beefing up the Index functions and of adding children I/O packages.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, August 27, 2002  9:21 AM
+
+> It's an entirely different thing to add a new overload with parameter/result
+> types that are likely to be used in conjunction with unbounded strings.
+
+OK, but in that case Robert is right - we can't add anything to any of the
+string packages (which includes new Index routines). And I don't think any of
+this is compelling enough to add child packages.
+
+> Interestingly enough, I don't remember agreeing to changes regarding slices
+> during the last meeting.  That may have been overheating, but then I see in
+> the minutes that "there is not much interest in the slice version of the
+> operations that were proposed".  The ARG in the other hand was in favor of
+> beefing up the Index functions and of adding children I/O packages.
+
+"Slice version" is the key words. The original proposal had slice versions of
+the routines like Delete and Insert, as well as ones taking Unbounded_String. I
+don't believe that there was much discussion on the orthogonolity routines
+(taking Unbounded_String parameters), but I'm sure that we didn't decide to
+drop them. The "Slice" function is one of the things that should return an
+Unbounded_String. (Note that in my opinion, this routine never should have
+returned String in the first place; the problem we have now is because of that
+mistake.)
+
+Anyway, without fixing the orthogonality, I don't see much benefit to this AI
+at all (especially since the Index changes also cannot be allowed); I'd vote it
+No Action in that case.
+
+****************************************************************
+
+From: Nick Roberts
+Sent: Tuesday, August 27, 2002  10:30 AM
+
+This may be a point that has been mentioned before, but I feel it
+ought to be mooted (again).
+
+I believe the primary rationale for introducing the
+Ada.Strings.Bounded and Ada.Strings.Unbounded packages into the
+standard was based on the assumption that compiler implementors
+could implement these packages more efficiently (using 'insider
+knowledge' and/or special machine code) than would be possible by
+writing them in 'pure' (portable) Ada.
+
+I suspect this rationale could be challenged (especially in the
+context of RISC targets). I am myself dubious about it. Were
+there other strong reasons for these packages being part of the
+standard?
+
+Would there be some sense in the idea of actually removing these
+packages from the next revision of the standard? Obviously they
+would have to remain available in practice, but their ongoing
+specification (and maybe testing) could fall under the
+jurisdiction of something separate from the (main) Ada language
+standard itself.
+
+Given the difficulties, in terms of time and manpower, the ARG
+has in developing the standard (with all respect), would this
+perhaps be a more pragmatic approach? I believe there are some
+who feel this is the way for a 'containers' facility to be added
+to Ada.
+
+I personally don't have strong feelings one way or the other, but
+it's perhaps something to consider.
+
+We are no doubt all agreed that 'versionism' is evil. However, it
+may be the lesser of two (or the least of several) evils to
+specify the string packages in two versions -- the original (as
+it is now) and the new (as improved by the proposal) -- and
+permit implementations to support either, or both (selected by
+some switch, option, or pragma perhaps), or even neither. In this
+case, it may be easier if they are no longer specified in the
+main Ada standard. Again, this is just an idea to consider.
+
+If I'm retreading already trodden ground, my apologies.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Tuesday, August 27, 2002  4:46 PM
+
+> I believe the primary rationale for introducing the
+> Ada.Strings.Bounded and Ada.Strings.Unbounded packages into the
+> standard was based on the assumption that compiler implementors
+> could implement these packages more efficiently (using 'insider
+> knowledge' and/or special machine code) than would be possible by
+> writing them in 'pure' (portable) Ada.
+
+I don't think that was the main reason.  I think these packages are
+included because they provide generally-useful functionality that would
+be useful to make portable.  In part, they are an answer to the
+complaint that the predefined String can't do X, Y, and Z, whereas in
+language Mumble, that functionality is standardly available.
+
+> Would there be some sense in the idea of actually removing these
+> packages from the next revision of the standard? Obviously they
+> would have to remain available in practice, but their ongoing
+> specification (and maybe testing) could fall under the
+> jurisdiction of something separate from the (main) Ada language
+> standard itself.
+
+I don't like the idea of removing them.
+
+Of course, anybody can create a better version of these packages, if
+they like.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, August 27, 2002  4:59 PM
+
+It is compeltely unacceptable to even consider removing useful functionality
+from the standard. This package Strings. Unbounded is in wide use and it would
+be unthinkable to remove it from the standard. It would give an impression of
+a standards process that had run amok!
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, August 27, 2002  4:28 PM
+
+I find the idea of a child I/O package reasonable. GNAT has provided that
+for some time. I assume the GNAT spec is in hand in this discussion?
+
+****************************************************************
 

Questions? Ask the ACAA Technical Agent