CVS difference for ai12s/ai12-0208-1.txt

Differences between 1.12 and version 1.13
Log of other versions for file ai12s/ai12-0208-1.txt

--- ai12s/ai12-0208-1.txt	2018/12/07 03:03:40	1.12
+++ ai12s/ai12-0208-1.txt	2018/12/07 03:37:05	1.13
@@ -1,4 +1,4 @@
-!standard A.5.5(0)                                   18-11-21  AI12-0208-1/05
+!standard A.5.5(0)                                   18-12-02  AI12-0208-1/06
 !standard A.5.6(0)
 !standard A.5.7(0)
 !standard A.5.8(0)
@@ -111,7 +111,7 @@
                        or else (raise Constraint_Error);
       end Unsigned_Conversions;
-      function To_String (Arg : Valid_Big_Integer
+      function To_String (Arg : Valid_Big_Integer;
                           Width : Field := 0;
                           Base  : Number_Base := 10) return String
          with Post => To_String'Result'First = 1;
@@ -144,7 +144,7 @@
    end Ada.Numerics.Big_Numbers.Big_Integers;
 To_String and From_String behave analogously to the Put and Get procedures
-defined in Text_Io.Integer_IO (in particular, with respect to the
+defined in Text_IO.Integer_IO (in particular, with respect to the
 interpretation of the Width and Base parameters) except that
 Constraint_Error, not Data_Error, is propagated in error cases
 and the result of a call To_String with a Width parameter of 0 and
@@ -153,7 +153,7 @@
 parameters), prepends a leading blank if the argument is
 nonnegative, converts that String to a Wide_Wide_String using
 To_Wide_Wide_String, and writes the resulting value to the stream using
-Wide_Wide_String'Write .
 The other functions have their usual mathematical meanings.
@@ -287,6 +287,9 @@
       function ">" (L, R : Valid_Big_Rational) return Boolean;
       function ">=" (L, R : Valid_Big_Rational) return Boolean;
+      function In_Range (Arg, Low, High : Valid_Big_Rational) return Boolean is
+        ((Low <= Arg) and (Arg <= High));
          type Num is digits <>;
       package Float_Conversions is
@@ -304,8 +307,8 @@
                           Aft  : Field := 3;
                           Exp  : Field := 0) return String
          with Post => To_String'Result'First = 1;
-      function From_String (Arg : Valid_Big_Rational;
-                            Width : Field := 0);
+      function From_String (Arg   : String;
+                            Width : Field := 0) return Valid_Big_Rational;
       function To_Quotient_String (Arg : Valid_Big_Rational) return String is
         (To_String (Numerator (Arg)) & " /" & To_String (Denominator (Arg)));
@@ -330,7 +333,7 @@
    end Ada.Numerics.Big_Numbers.Big_Rationals;
 To_String and From_String behave analogously to the Put and Get procedures
-defined in Text_Io.Float_IO (in particular, with respect to the
+defined in Text_IO.Float_IO (in particular, with respect to the
 interpretation of the Fore, Aft, Exp, and Width parameters), except that
 Constraint_Error (not Data_Error) is propagated in error cases.
 From_Quotient_String implements the inverse function of To_Quotient_String;
@@ -375,7 +378,7 @@
 This section, or at least the AARM note, is intended to follow
-the structure of the analogous wording for  AI12-0112 (contracts for
+the structure of the analogous wording for  AI12-0112-1 (contracts for
 Add after 11.5(23):
@@ -3608,5 +3611,169 @@
 Hopefully, all the right rules are in place for deciding when you get a
 leading blank on the image of a positive integer.
+From: Jeff Cousins
+Sent: Friday, November 23, 2018  1:06 PM
+Thanks Steve.  A few comments:
+Big_Integers function To_String is missing the  ; after the  first parameter.
+I think you need to define deferred constants for zero and unity.
+Big_Integers spurious space after Wide_Wide_String’Write.
+Big_Rationals – I think you need to define a Rationals version of In_Range for
+use in Float_Conversions.
+Big_Rationals From_String should have an Arg of String not Valid_Big_Rational,
+and should return Valid_Big_Rational.
+Text_Io -> Text_IO (two places).
+From: Randy Brukardt
+Sent: Monday, November 26, 2018  9:19 PM
+>I think you need to define deferred constants for zero and unity.
+Why? We have numeric literals in these packages (thanks to that new
+mechanism), so just using 0 and 1 are many times more likely. I would expect
+very few people would even think to use such constants. If you had to write:
+     V := Ada.Numerics.Big_Numbers.Big_Integers.From_String ("0"); or
+     V := Ada.Numerics.Big_Numbers.Big_Integers.From_Integer (0);
+I could see that. Even with use clauses, these would be annoying. But with
+     V := 0;
+is obvious. I don't see anyone wanting to write:
+     V := Ada.Numerics.Big_Numbers.Big_Integers.Zero;
+instead. (Especially for those of us in the "use type" only camp.)
+From: Jeff Cousins
+Sent: Tuesday, November 27, 2018  6:51 AM
+Ok, I suppose I’d never really digested what AI-0249 was for.
+But without AI-0249, wouldn’t deferred constants have been needed to get
+from universal type 0 and 1 to private type 0 and 1 for use in the contracts?
+More justification for AI-0249 I suppose.
+PS. (Chit chat) I became a grandad yesterday, Charlie John Cousins was born
+From: Tucker Taft
+Sent: Tuesday, November 27, 2018  9:00 AM
+Good point.  In fact, there is a bit of a delicate dance going on here in the
+contracts.  We are using the literals 0 and 1, as you point out.  Name
+resolution on aspect specifications isn't performed until the word "private."
+The question is whether things are done in the right order.  In particular the
+aspect specification on Big_Integer saying "Integer_Literal => From_String"
+needs to be processed to some degree before we try to interpret the aspect
+specification "Dynamic_Predicate => Big_Positive > 0" since the implicit
+conversion from Universal-integer "0" to Big_Integer depends on it.   Perhaps
+the "Integer_Literal =>" part can have an immediate effect, while the name
+resolution of the "From_String" part can be postponed until the word
+Steve?  Others?
+>PS. (Chit chat) I became a grandad yesterday, Charlie John Cousins was born
+Great news, Gramps!
+From: Randy Brukardt
+Sent: Tuesday, November 27 2018  6:01 PM
+I've thought about this some this afternoon, and I don't think there is a real
+problem, but there definitely is a dance.
+It's known as soon as the aspect is used that (integer, in this case) literals
+can be used. (That sort of property seems like it would be useful for many
+aspects, for instance generalized indexing.) That's clear because the name of
+aspect is given in the type_declaration; that can't be altered by later
+declarations. But we don't need to know the precise meaning of those literals
+until an expression containing one is *evaluated*.
+Remember that preconditions and default expressions and many other expressions
+are *not* evaluated when they are seen. So the compiler can allow the use of
+literals in those expressions without having to know how they are interpreted
+in the future. Moreover, an expression that is evaluated (such as the
+initializer of an object) freezes the type. And freezing the type evaluates
+the aspects, so the details of evaluation are known before the evaluation
+is actually done.
+Combined with the rules that prevent a literal from having a different meaning
+for the full type, means to me that there is no problem allowing the use of
+literals as soon as aspect Integer_Literal is seen, even though the exact
+meaning of the aspect is not yet known. If the aspect turns out to have
+been illegal for some reason, then the compilation unit will be rejected
+before anyone tries to evaluate the literals -- and otherwise, we'll known in
+Whether the wording in 13.1.1 and elsewhere actually imply this model, or
+whether we need some extra wording to get it, I'll leave to the
+hair-splitters of the ARG. (Gotta get back to finishing the minutes in any
+>>PS. (Chit chat) I became a grandad yesterday, Charlie John Cousins was born ??
+>Great news, Gramps!
+Second that!
+From: Steve Baird
+Sent: Sunday, December 2, 2018  1:08 PM
+Thanks as always for the careful reading.
+The attached [version /06 - Editor.] is intended to include the corrections
+you suggested except for the stuff about deferred constants for zero and one,
+which I think was  determined to be ok as it is in subsequent discussions. We
+may or may not (I haven't tried to determine this yet) need a separate AI to
+support Randy's  argument that it is ok to use user-defined literals in aspect
+specifications as is done in this spec; I believe Randy's argument is correct
+- it is just a question of whether it is supported by existing RM wording.
+Incidentally, identifying that issue was a good catch!
+Upon rereading, I wonder whether we should delete the Width parameters from
+the From_String functions. Do those make sense for a function that is passed
+a String (as opposed to reading characters from a file)?
+If we decide to do this, then we should also delete the mention of Width in
+the accompanying text for Big_Rationals (but not in the corresponding text
+for Big_Integers) because with this change there will no longer be any
+subprograms in the Big_Rationals spec that take a Width parameter.
+From: Randy Brukardt
+Sent: Thursday, December  6, 2018  9:36 PM
+There's one necessary correction that no one suggested: the 11.5(23) text calls
+the package "Ada.Big_Numbers", but it obviously is called
+"Ada.Numerics.Big_Numbers". There are three occurrences. I've fixed them all.
+(There also was a stray blank in here.)
+Also the AI number in the preceding note is missing the '2': AI12-0112-1, not
+"AI12-011". Also fixed.

Questions? Ask the ACAA Technical Agent