CVS difference for ais/ai-00301.txt

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

--- ais/ai-00301.txt	2005/08/21 06:00:26	1.20
+++ ais/ai-00301.txt	2005/10/31 05:18:27	1.21
@@ -1,4 +1,4 @@
-!standard A.4.3(8)                                   05-08-10  AI95-00301/14
+!standard A.4.3(8)                                   05-09-20  AI95-00301/15
 !standard A.4.3(10)
 !standard A.4.3(11)
 !standard A.4.3(56)
@@ -378,8 +378,8 @@
    of the number of characters read. Reading stops when the end of the line is
    met; Skip_Line is then (in effect) called with a spacing of 1.
 
-   Constraint_Error is raised if the length of line exceeds Positive'Last; in
-   the case, the line number and page number are unchanged, and the column
+   Constraint_Error is raised if the length of the line exceeds Positive'Last;
+   in this case, the line number and page number are unchanged, and the column
    number is unspecified but no less than it was before the call.
    The exception End_Error is propagated if an attempt is made to skip a file
    terminator.
@@ -673,7 +673,7 @@
                    Test    : @b<in> Membership := Inside;
                    Going   : @b<in> Direction := Forward)
       @b<return> Natural;>
-@dinsa
+@dinst
 @xcode<   @b<function> Index_Non_Blank (Source : @b<in> String;
                              From   : @b<in> Positive;
                              Going  : @b<in> Direction := Forward)
@@ -1011,9 +1011,9 @@
 !corrigendum A.10.7(13)
 
 @drepl
-For an item of type String, the following procedures are provided:
+For an item of type String the following procedures are provided:
 @dby
-For an item of type String, the following subprograms are provided:
+For an item of type String the following subprograms are provided:
 
 !corrigendum A.10.7(17)
 
@@ -1031,8 +1031,11 @@
 of the number of characters read. Reading stops when the end of the line is
 met; Skip_Line is then (in effect) called with a spacing of 1.>
 
-@xindent<The exception End_Error is propagated if an attempt is made to skip
-a file terminator.>
+@xindent<Constraint_Error is raised if the length of the line exceeds
+Positive'Last; in this case, the line number and page number are unchanged, and
+the column number is unspecified but no less than it was before the call. The
+exception End_Error is propagated if an attempt is made to skip a file
+terminator.>
 
 !corrigendum A.10.12(01)
 
@@ -1509,7 +1512,7 @@
 --                                                                          --
 --                                 S p e c                                  --
 --                                                                          --
---    $Revision: 1.20 $                              --
+--                            $Revision: 1.21 $                              --
 --                                                                          --
 --          Copyright (C) 1992-1998, Free Software Foundation, Inc.         --
 --                                                                          --
@@ -3782,3 +3785,489 @@
 > as a way to avoid Storage_Error?
 
 ****************************************************************
+
+From: Robert Dewar
+Sent: Sunday, February  6, 2005  1:02 PM
+
+I think it would be worth a note in the RM that the use of
+the functional form of Get_Line for other than Unbounded_String
+is likely to consume large amounts of stack space (without really
+specialized processing known to the compiler, I see no choice here.
+In fact it takes a little bit of care to get linear stack usage
+with the line size, as opposed to quadratic space usage without
+using the heap :-)
+
+Regarding the new unbounded string i/o operations, it seems a bit
+strange for these to be a child of Text_IO, as opposed to a child
+of Unbounded. Why? Because an efficient implementation will surely
+need to break the unbounded string abstraction (you can't just use
+the Text_IO function for the reason given above in the first para).
+But you don't need to break the Text_IO abstraction.
+
+In GNAT, this package has always been a child of Unbounded, and
+of course we will keep it there for back compatibility. I have
+provided the new package as a set of renamings, but I wonder if
+we made the right choice here.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Sunday, February  6, 2005  2:35 PM
+
+Which AI do you mean?  AI-048 is something about RCI procedure...
+
+> I think it would be worth a note in the RM that the use of
+> the functional form of Get_Line for other than Unbounded_String
+> is likely to consume large amounts of stack space (without really
+> specialized processing known to the compiler, I see no choice here.
+> In fact it takes a little bit of care to get linear stack usage
+> with the line size, as opposed to quadratic space usage without
+> using the heap :-)
+
+I don't understand this efficiency concern.  Please explain.
+Also, are you talking about very long lines, or typical lines?
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Sunday, February  6, 2005  5:58 PM
+
+> Which AI do you mean?  AI-048 is something about RCI procedure...
+
+ARRGH! finger's typing not under control of brain. I meant AI-301
+
+> I don't understand this efficiency concern.  Please explain.
+> Also, are you talking about very long lines, or typical lines?
+
+I mean for very long lines, since you are returning a String, you
+cannot avoid using at least a corresponding amount of stack space,
+even if you are willing to temporarily use the heap. If you don't
+want to use the heap, then you have to be quite careful not to use
+up a quadratic amount of space on the stack (the GNAT implementation
+shown below (Pascal, don't scroll down :-)) uses a linear amount of
+stack, something like 2-3 times length of string in worse case.
+
+On another related manner, Unbounded_IO (from the same AI):
+
+I think it is an omission not to have this Get_Line routine for
+at least Strings.Fixed, because in that case you can use the
+heap and avoid excessive stack use.
+
+I would also add this for Strings.Bounded, since the whole idea
+is to be able to replace Strings.Unbounded with Strings.Bounded
+when you want to avoid use of the
+
+In GNAT, we will certainly add these two packages
+
+
+scroll down for GNAT implementation of Get_Line function ...
+
+
+
+
+
+    function Get_Line (File : File_Type) return String is
+       Buffer : String (1 .. 500);
+       Last   : Natural;
+
+       function Get_Rest (S : String) return String;
+       --  This is a recursive function that reads the rest of the line and
+       --  returns it. S is the part read so far.
+
+       --------------
+       -- Get_Rest --
+       --------------
+
+       function Get_Rest (S : String) return String is
+
+          --  Each time we allocate a buffer the same size as what we have
+          --  read so far. This limits us to a logarithmic number of calls
+          --  to Get_Rest and also ensures only a linear use of stack space.
+
+          Buffer : String (1 .. S'Length);
+          Last   : Natural;
+
+       begin
+          Get_Line (File, Buffer, Last);
+
+          declare
+             R : constant String := S & Buffer (1 .. Last);
+          begin
+             if Last < Buffer'Last then
+                return R;
+             else
+                return Get_Rest (R);
+             end if;
+          end;
+       end Get_Rest;
+
+    --  Start of processing for Get_Line
+
+    begin
+       Get_Line (File, Buffer, Last);
+
+       if Last < Buffer'Last then
+          return Buffer (1 .. Last);
+       else
+          return Get_Rest (Buffer (1 .. Last));
+       end if;
+    end Get_Line;
+
+
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, February  7, 2005  7:23 PM
+
+...
+> Regarding the new unbounded string i/o operations, it seems a bit
+> strange for these to be a child of Text_IO, as opposed to a child
+> of Unbounded. Why? Because an efficient implementation will surely
+> need to break the unbounded string abstraction (you can't just use
+> the Text_IO function for the reason given above in the first para).
+> But you don't need to break the Text_IO abstraction.
+
+We discussed that in Vienna (as recorded in the !appendix of the AI), and
+decided to be consistent with Complex_IO (a similar package in Ada 95). It
+was felt that getting access to the representation was not going to be a
+problem in practice (I'm not sure why that was - perhaps we all had heat
+related hallucinations... I think it has something to do with
+implementation-defined children.)
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, February  7, 2005  7:34 PM
+
+> We discussed that in Vienna (as recorded in the !appendix of the AI), and
+> decided to be consistent with Complex_IO (a similar package in Ada 95). It
+> was felt that getting access to the representation was not going to be a
+> problem in practice (I'm not sure why that was - perhaps we all had heat
+> related hallucinations... I think it has something to do with
+> implementation-defined children.)
+
+TO me these are far more part of the Unbounded abstraction, and getting
+hold of the representations is a bit of a problem, though obviously
+solvable by introducing some child units under Unbounded, which is
+what we do (in fact in GNAT, the spec of Ada.Text_IO.Unbounded_IO
+is just a bunch of renamings from the package we have always
+provided Ada.Strings.Unbounded.Text_IO.
+
+Not a big deal certainly, but an extra argument would have been
+to be consistent with what GNAT has provided for years (and no
+one ever complained about inconsistency :-)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, February  7, 2005  7:31 PM
+
+> On another related manner, Unbounded_IO (from the same AI)
+>
+> I think it is an omission not to have this Get_Line routine for
+> at least Strings.Fixed, because in that case you can use the
+> heap and avoid excessive stack use.
+
+That doesn't make much sense, as Ada.Strings.Fixed is just operations on
+type String. Thus, it would be identical to that provided by Text_IO.
+Moreover, you can't have Ada.Text_IO.Fixed_IO -- there already is such a
+thing.
+
+> I would also add this for Strings.Bounded, since the whole idea
+> is to be able to replace Strings.Unbounded with Strings.Bounded
+> when you want to avoid use of the
+
+Ada.Text_IO.Bounded_IO has to be generic with a formal package parameter.
+That's ugly and eliminates any hope of "easy to use". Given that we can't be
+completely consistent - as noted above, doing this for Fixed is both
+redundant and ends up with a conflicting name - we decided to just not
+bother defining it. (Which doesn't prevent you from doing so.)
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, February  7, 2005  7:34 PM
+
+...
+> That doesn't make much sense, as Ada.Strings.Fixed is just operations on
+> type String. Thus, it would be identical to that provided by Text_IO.
+
+hmm . I was thinking in terms of a get routine that returns a pointer
+to string, but I see what you mean.
+
+> Moreover, you can't have Ada.Text_IO.Fixed_IO -- there already is such a
+
+No, but you can have Ada.Strings.Fixed.Text_IO -- another reason for
+doing things that way round.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, February  7, 2005  9:29 AM
+
+What happens if the value for From in a call to Index is less than
+Source'First. I would think the answer should be CE, but the current
+wording is not clear, you could just decide that the non-existent
+positions of Source don't have the pattern.
+
+I think it is clean if the effect is declared identical to
+calling the non-From routine with Source (From .. Source'Last).
+I must say I am a bit mystefied that you only get to specify
+a From value and not a To value in these calls -- what's the
+logic behind that inconsistency?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, February  7, 2005  7:43 PM
+
+> What happens if the value for From in a call to Index is less than
+> Source'First. I would think the answer should be CE, but the current
+> wording is not clear, you could just decide that the non-existent
+> positions of Source don't have the pattern.
+
+This looks like a bug. I'll fix it up as an editorial change.
+
+> I think it is clean if the effect is declared identical to
+> calling the non-From routine with Source (From .. Source'Last).
+
+The wording makes the non-From routine the same as the From routine with
+From = Source'First. We can't have it both ways!
+
+> I must say I am a bit mystefied that you only get to specify
+> a From value and not a To value in these calls -- what's the
+> logic behind that inconsistency?
+
+There was great concern from some quarters about too much modification to
+these packages. We had an identified problem that From is intended to solve
+(finding all occurrences of a pattern in a [un]bounded string); we didn't
+have such a problem for To. The other problem is that there is no obvious
+default value for these parameters (you can't default to an expression of
+another parameter, which is what you want). So you'd have to provide all
+four permutations, which looks like overkill, or you'd force the programmer
+to specify the string in question multiple times, which is a source of
+errors. I certainly don't want to have to say:
+     Position := Ada.Strings.Unbounded.Index (
+        Some_Long_Array_of_Unbounded(Some_Messy_Index),
+        Pattern => "Fooey",
+        From => Last_Position+1,
+        To => Ada.Strings.Unbounded.
+               Length(Some_Long_Array_of_Unbounded(Some_Messy_Index));
+all over the place. (And yes, my spam filter is full of the above call,
+without the "To" parameter.)
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, February  7, 2005  8:31 PM
+
+> The other problem is that there is no obvious
+> default value for these parameters (you can't default to an expression of
+> another parameter, which is what you want).
+
+Sure there is an obvious default, and I would like to see it added.
+Just use -1 to indicate that you are not supplying a From value.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, February  7, 2005  8:51 PM
+
+> Sure there is an obvious default, and I would like to see it added.
+> Just use -1 to indicate that you are not supplying a From value.
+
+Yuck. That looks like C. Besides, to do that, you'd have to change the
+parameter types from Positive to Integer (or declare a special subtype for
+this purpose), which would be inconsistent with all of the other string
+routines.
+
+We thought about using 0 for this purpose (and Natural for the subtype), but
+that would cover up off-by-one errors and wouldn't work at all for To.
+Overloading works better.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, February  7, 2005  9:08 PM
+
+> Yuck. That looks like C. Besides, to do that, you'd have to change the
+> parameter types from Positive to Integer (or declare a special subtype for
+> this purpose), which would be inconsistent with all of the other string
+> routines.
+
+No, it doesn't look like C. That's the point. There are no default params
+in C, so this kind of nonsense gets exposed. A nice general technique
+in Ada is that default values like this are in effect pretty much hidden,
+since they don't appear in the application code.
+
+Actually it would be nice to have a 'Present test to see whether a parameter
+was defaulted or not, but oh well ...
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, February  7, 2005  9:00 PM
+
+> This looks like a bug. I'll fix it up as an editorial change.
+
+For the record, I wrote this as raising Index_Error, to be consistent with
+the other routines in Ada.Strings.Fixed that take indexes (like Insert,
+Overwrite, and Replace_Slice).
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, February  7, 2005  9:11 PM
+
+> For the record, I wrote this as raising Index_Error, to be consistent with
+> the other routines in Ada.Strings.Fixed that take indexes (like Insert,
+> Overwrite, and Replace_Slice).
+
+Oh can't it just raise Constraint_Error? Then you get it for free in
+the check that is done by the slice. Oh well, no big deal, not that
+much trouble to put in the test (in 12 different places. I will
+personally throttle anyone who wants to add Wide_Wide_Wide_Character
+to Ada 2015 if I am stil around :-)
+
+P.S. One thing I wonder. I had to write nine run time routines
+to deal with
+
+[Wide_[Wide_]]Width applied to [[Wide_]Wide_]Character types with
+dynamic ranges, and they are not trivial routines. Is this amount of
+nonsense really intended by the language?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, February  7, 2005  9:36 PM
+
+> Oh can't it just raise Constraint_Error? Then you get it for free in
+> the check that is done by the slice.
+
+I know, but the packages consistently raise Index_Error, and I'm pretty
+certain if I put in Constraint_Error, someone will make me change it. :-)
+Might as well save everyone the aggrevation. (Ada.Strings.Fixed should have
+just raised Constraint_Error everywhere.)
+
+> Oh well, no big deal, not that
+> much trouble to put in the test (in 12 different places. I will
+> personally throttle anyone who wants to add Wide_Wide_Wide_Character
+> to Ada 2015 if I am stil around :-)
+
+Please do. I certainly am no fan of Wide_Wide_Character, starting with the
+name...
+
+> P.S. One thing I wonder. I had to write nine run time routines
+> to deal with
+>
+> [Wide_[Wide_]]Width applied to [[Wide_]Wide_]Character types with
+> dynamic ranges, and they are not trivial routines. Is this amount of
+> nonsense really intended by the language?
+
+Only 9? We must be slipping. :-) :-)
+
+Personally, I don't understand why 'Width had to be so complicated, but I
+think we're pretty much stuck with it -- can't break all of the code out
+there that uses it. I would think that some of the combinations could be
+implemented by calling another routine (Wide_Wide_Width of Character seems
+the same as Wide_Width of Character, etc.), but still there are a lot of
+cases.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, February  7, 2005  9:48 PM
+
+I think width for enumeration types should just have gone to the base type.
+It is simply too much silly work to deal with dynamic ranges at run time
+searching the image table to find the longest one.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, February  7, 2005  7:44 PM
+
+note that there is some wide wide stuff to be
+added to AI-301.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, February  7, 2005  8:05 PM
+
+Ada.Wide_Text_IO.Wide_Unbounded_IO and
+Ada.Wide_Wide_Text_IO.Wide_Wide_Unbounded_IO are covered in A.11(4/2). [Yes,
+I caught that one.]
+
+Is there anything else? I can't think of anything off-hand (the changes to
+Ada.String.Unbounded, etc. happen automatically, of course, because of the
+way that A.4.7 and A.4.8 are written).
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, February  7, 2005  8:45 PM
+
+No, actually I think that's OK, I forgot about the general A.4.7 and
+A.4.8 stuff (of course I executed A.4.7 and A.4.8 before doing 301 :-)
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, February  8, 2005  9:50 PM
+
+I assume Set_[Un]bounded_String
+becomes Set_[[Wide_]Wide_]Unbounded_String
+
+and ditto for Bounded, requiring two new transation rules.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, February  9, 2005  8:29 PM
+
+I wouldn't *assume* anything; certainly we don't have any such rules.
+
+But it certainly seems that such rules are intended and were just
+overlooked. I'll add them as a correction to the two AIs in question.
+
+Note that this also applies to [Un]bounded_Slice.
+
+Thanks for noting it.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, February  9, 2005  8:42 PM
+
+> Note that this also applies to [Un]bounded_Slice.
+
+Do you think so, do we really need to call these things
+Unbounded_Wide_Slice, seems unnecessary to me.
+
+****************************************************************
+From: Randy Brukardt
+Sent: Wednesday, February  9, 2005  8:41 PM
+
+> Note that this also applies to [Un]bounded_Slice.
+
+Actually, I think it doesn't apply to Slice. The existing ones change from
+    To_Bounded_String => To_Bounded_Wide_String
+(I'd have never guessed that! - the package name is "Wide_Bounded", after
+all.)
+So "Wide" associates with "String", not "Bounded". Thus, there is no need to
+change "Slice" to "Wide_Slice" (what's that?), and Robert's change given
+above is wrong; it should be:
+    Set_[Un]bounded_[[Wide_]Wide_]String
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, February  9, 2005  8:42 PM
+
+Yes, I agree with all the above reasoning, and in fact I had implemented
+the Set_[Un]bounded_[[Wide_]Wide_]String form :-) since it just fell out.
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent