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

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

--- ai12s/ai12-0208-1.txt	2019/03/15 05:41:41	1.24
+++ ai12s/ai12-0208-1.txt	2019/03/16 02:34:23	1.25
@@ -1,4 +1,4 @@
-!standard A.5.5(0)                                   19-02-26  AI12-0208-1/10
+!standard A.5.5(0)                                   19-03-15  AI12-0208-1/11
 !standard A.5.6(0)
 !standard A.5.7(0)
 !class Amendment 16-12-19
@@ -31,7 +31,7 @@
 than those supported by the target machine, and for arbitrary-precision
 reals.
 
-The package Ada.Numerics.Big_Numbers has the following declaration:
+The library package Numerics.Big_Numbers has the following declaration:
 
    package Ada.Numerics.Big_Numbers
       with Pure, Nonblocking, Global => null
@@ -42,7 +42,7 @@
 
 A.5.6 Big Integers
 
-The package Ada.Numerics.Big_Numbers.Big_Integers has the
+The library package Numerics.Big_Numbers.Big_Integers has the
 following declaration:
 
    with Ada.Streams;
@@ -96,8 +96,8 @@
 
       function To_Integer (Arg : Big_Integer) return Integer
         with Pre => In_Range (Arg,
-                              Low => +Integer'First,
-                              High => +Integer'Last)
+                              Low  => To_Big_Integer (Integer'First),
+                              High => To_Big_Integer (Integer'Last))
                     or else (raise Constraint_Error);
 
       generic
@@ -129,8 +129,8 @@
       function From_String (Arg : String) return Big_Integer;
 
       procedure Put_Image
-        (Arg    : Big_Integer;
-         Stream : not null access Ada.Streams.Root_Stream_Type'Class);
+        (Stream : not null access Ada.Streams.Root_Stream_Type'Class;
+         Arg    : Big_Integer);
 
       function "+" (L : Big_Integer) return Big_Integer;
       function "-" (L : Big_Integer) return Big_Integer;
@@ -168,7 +168,7 @@
 
 The other functions have their usual mathematical meanings.
 
-The type Optional_Big_Integer requires finalization.
+The type Optional_Big_Integer needs finalization (see 7.6).
 
 Implementation Requirements
   No storage associated with an Optional_Big_Integer object shall be lost upon
@@ -187,7 +187,7 @@
 
 A.5.7 Big Reals
 
-The package Numerics.Big_Numbers.Big_Reals has the
+The library package Numerics.Big_Numbers.Big_Reals has the
 following declaration:
 
    with Ada.Numerics.Big_Numbers.Big_Integers;
@@ -196,7 +196,7 @@
       with Preelaborate, Nonblocking.
            Global => in out synchronized Big_Reals
       is
- 
+
       type Optional_Big_Real is private with
         Default_Initial_Condition => not Is_Valid (Optional_Big_Real),
         Real_Literal => From_String,
@@ -212,7 +212,7 @@
              Predicate_Failure => (raise Constraint_Error);
 
       function "/" (Num, Den : Big_Integer) return Big_Real
-        with Pre => (if Big_Integers."/=" (Den, 0) 
+        with Pre => (if Big_Integers."=" (Den, 0)
                      then raise Constraint_Error);
 
       function Numerator (Arg : Big_Real) return Big_Integer;
@@ -272,9 +272,9 @@
         (To_String (Numerator (Arg)) & " / " & To_String (Denominator (Arg)));
       function From_Quotient_String (Arg : String) return Big_Real;
 
-      procedure Put_Image
-        (Arg    : Big_Real;
-         Stream : not null access Ada.Streams.Root_Stream_Type'Class);
+      procedure> Put_Image
+        (Stream : not null access> Ada.Streams.Root_Stream_Type'Class;
+         Arg    : Big_Real);
 
       function "+" (L : Big_Real) return Big_Real;
       function "-" (L : Big_Real) return Big_Real;
@@ -301,7 +301,7 @@
 the resulting value to the stream using Wide_Wide_String'Write.
 
 For an instance of Float_Conversions or Fixed_Conversions, To_Big_Real
-is exact (i.e., the result represents exactly the same
+is exact (that is, the result represents exactly the same
 mathematical value as the argument) and From_Big_Real is subject to
 the same precision rules as a type conversion of a value of type T to
 the target type Num, where T is a hypothetical floating point type whose
@@ -310,6 +310,8 @@
 
 The other functions have their usual mathematical meanings.
 
+The type Optional_Big_Real needs finalization (see 7.6).
+
 Implementation Requirements
   No storage associated with an Optional_Big_Real object shall be lost
   upon assignment or scope exit.
@@ -330,6 +332,308 @@
 We presume that AI12-0311-1 is approved, which will allow the preconditions
 and predicates of these packages to be suppressed.
 
+!corrigendum A.5.5(0)
+
+@dinsc
+
+Support is provided for integer arithmetic involving values larger than
+than those supported by the target machine, and for arbitrary-precision
+reals.
+
+@s8<@i<Static Semantics>>
+
+The library package Numerics.Big_Numbers has the following declaration:
+
+@xcode<@b<package> Ada.Numerics.Big_Numbers
+   @b<with> Pure, Nonblocking, Global =@> @b<null is>
+   @b<subtype> Field @b<is> Integer @b<range> 0 .. @ft<@i<implementation-defined>>;
+   @b<subtype> Number_Base @b<is> Integer @b<range> 2 .. 16;
+@b<end> Ada.Numerics.Big_Numbers;>
+
+!corrigendum A.5.6(0)
+
+@dinsc
+
+@s8<@i<Static Semantics>>
+
+The library package Numerics.Big_Numbers.Big_Integers has the
+following declaration:
+
+@xcode<@b<with> Ada.Streams;
+@b<package> Ada.Numerics.Big_Numbers.Big_Integers
+   @b<with> Preelaborate, Nonblocking,
+        Global =@> @b<in out synchronized> Big_Integers
+   @b<is>>
+
+@xcode<   @b<type> Optional_Big_Integer @b<is private>
+      @b<with> Default_Initial_Condition =@> @b<not> Is_Valid (Optional_Big_Integer),
+           Integer_Literal =@> From_String,
+           Put_Image =@> Put_Image;>
+
+@xcode<   @b<function> Is_Valid (Arg : Optional_Big_Integer) @b<return> Boolean;>
+
+@xcode<   @b<subtype> Big_Integer @b<is> Optional_Big_Integer
+      @b<with> Dynamic_Predicate =@> Is_Valid (Big_Integer),
+           Predicate_Failure =@> (@b<raise> Constraint_Error);>
+
+@xcode<   @b<function> Invalid_Big_Integer @b<return> Optional_Big_Integer
+      @b<with> Post =@> @b<not> Is_Valid (Invalid_Big_Integer'Result);>
+
+@xcode<   @b<function> "=" (L, R : Big_Integer) @b<return> Boolean;
+   @b<function> "<" (L, R : Big_Integer) @b<return> Boolean;
+   @b<function> "<=" (L, R : Big_Integer) @b<return> Boolean;
+   @b<function> "@>" (L, R : Big_Integer) @b<return> Boolean;
+   @b<function> "@>=" (L, R : Big_Integer) @b<return> Boolean;>
+
+@xcode<   @b<function> To_Big_Integer (Arg : Integer) @b<return> Big_Integer;>
+
+@xcode<   @b<subtype> Optional_Big_Positive @b<is> Optional_Big_Integer
+      @b<with> Dynamic_Predicate =@> (@b<not> Is_Valid (Optional_Big_Positive))
+                                 @b<or else> (Optional_Big_Positive @> 0),
+           Predicate_Failure =@> (@b<raise> Constraint_Error);>
+
+@xcode<   @b<subtype> Optional_Big_Natural @b<is> Optional_Big_Integer
+      @b<with> Dynamic_Predicate =@> (@b<not> Is_Valid (Optional_Big_Natural))
+                                 @b<or else> (Optional_Big_Natural @>= 0),
+           Predicate_Failure =@> (@b<raise> Constraint_Error);>
+
+@xcode<   @b<subtype> Big_Positive @b<is> Big_Integer
+      @b<with> Dynamic_Predicate =@> Big_Positive @> 0,
+           Predicate_Failure =@> (@b<raise> Constraint_Error);>
+
+@xcode<   @b<subtype> Big_Natural @b<is> Big_Integer
+      @b<with> Dynamic_Predicate =@> Big_Natural @>= 0,
+           Predicate_Failure =@> (@b<raise> Constraint_Error);>
+
+@xcode<   @b<function> In_Range (Arg, Low, High : Big_Integer) @b<return> Boolean @b<is>
+      ((Low <= Arg) @b<and> (Arg <= High));>
+
+@xcode<   @b<function> To_Integer (Arg : Big_Integer) @b<return> Integer
+      @b<with> Pre =@> In_Range (Arg,
+                            Low  =@> To_Big_Integer (Integer'First),
+                            High =@> To_Big_Integer (Integer'Last))
+                   @b<or else> (@b<raise> Constraint_Error);>
+
+@xcode<   @b<generic>
+      @b<type> Int @b<is range> <@>;
+   @b<package> Signed_Conversions @b<is>
+      @b<function> To_Big_Integer (Arg : Int) @b<return> Big_Integer;
+      @b<function> From_Big_Integer (Arg : Big_Integer) @b<return> Int
+         @b<with> Pre =@> In_Range (Arg,
+                               Low  =@> To_Big_Integer (Int'First),
+                               High =@> To_Big_Integer (Int'Last))
+                      @b<or else> (@b<raise> Constraint_Error);
+   @b<end> Signed_Conversions;>
+
+@xcode<   @b<generic>
+      @b<type> Int @b<is mod> <@>;
+   @b<package> Unsigned_Conversions @b<is>
+      @b<function> To_Big_Integer (Arg : Int) @b<return> Big_Integer;
+      @b<function> From_Big_Integer (Arg : Big_Integer) @b<return> Int
+         @b<with> Pre =@> In_Range (Arg,
+                               Low  =@> To_Big_Integer (Int'First),
+                               High =@> To_Big_Integer (Int'Last))
+                      @b<or else> (@b<raise> Constraint_Error);
+   @b<end> Unsigned_Conversions;>
+
+@xcode<   @b<function> To_String (Arg : Big_Integer;
+                       Width : Field := 0;
+                       Base  : Number_Base := 10) @b<return> String
+      @b<with> Post =@> To_String'Result'First = 1;
+   @b<function> From_String (Arg : String) @b<return> Big_Integer;>
+
+@xcode<   @b<procedure> Put_Image
+      (Stream : @b<not null access> Ada.Streams.Root_Stream_Type'Class;
+       Arg    : Big_Integer);>
+       
+@xcode<   @b<function> "+" (L : Big_Integer) @b<return> Big_Integer;
+   @b<function> "-" (L : Big_Integer) @b<return> Big_Integer;
+   @b<function> "abs" (L : Big_Integer) @b<return> Big_Integer;
+   @b<function> "+" (L, R : Big_Integer) @b<return> Big_Integer;
+   @b<function> "-" (L, R : Big_Integer) @b<return> Big_Integer;
+   @b<function> "*" (L, R : Big_Integer) @b<return> Big_Integer;
+   @b<function> "/" (L, R : Big_Integer) @b<return> Big_Integer;
+   @b<function> "mod" (L, R : Big_Integer) @b<return> Big_Integer;
+   @b<function> "rem" (L, R : Big_Integer) @b<return> Big_Integer;
+   @b<function> "**" (L : Big_Integer; R : Natural)
+      @b<return> Big_Integer;
+   @b<function> Min (L, R : Big_Integer) @b<return> Big_Integer;
+   @b<function> Max (L, R : Big_Integer) @b<return> Big_Integer;>
+
+@xcode<   @b<function> Greatest_Common_Divisor
+      (L, R : Big_Integer) @b<return> Big_Positive
+      @b<with> Pre =@> (L /= 0 @b<and> R /= 0) @b<or else> (@b<raise> Constraint_Error);>
+
+@xcode<@b<private>
+   ... -- @ft<@i<not specified by the language>>
+@b<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
+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
+a nonnegative Arg parameter does not include a leading blank.
+Put_Image calls To_String (passing in the default values for the Width and Base
+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.
+
+The type Optional_Big_Integer needs finalization (see 7.6).
+
+@s8<@i<Implementation Requirements>>
+
+No storage associated with an Optional_Big_Integer object shall be lost upon
+assignment or scope exit.
+
+For purposes of determining whether predicate checks are performed
+as part of default initialization, the type Optional_Big_Integer
+shall be considered to have a subcomponent that has a @fa<default_expression>.
+
+
+!corrigendum A.5.7(0)
+
+@dinsc
+
+@s8<@i<Static Semantics>>
+
+The library package Numerics.Big_Numbers.Big_Reals has the
+following declaration:
+
+@xcode<@b<with> Ada.Numerics.Big_Numbers.Big_Integers;
+@b<with> Ada.Streams;
+@b<package> Ada.Numerics.Big_Numbers.Big_Reals
+   @b<with> Preelaborate, Nonblocking,
+        Global =@> @b<in out synchronized> Big_Reals
+   @b<is>>
+
+@xcode<   @b<type> Optional_Big_Real @b<is private>
+     @b<with> Default_Initial_Condition =@> @b<not> Is_Valid (Optional_Big_Real),
+          Real_Literal =@> From_String,
+          Put_Image =@> Put_Image;>
+
+@xcode<   @b<function> Is_Valid (Arg : Optional_Big_Real) @b<return> Boolean;>
+
+@xcode<   @b<function> No_Big_Real @b<return> Optional_Big_Real
+      @b<with> Post =@> @b<not> Is_Valid (No_Big_Real'Result);>
+
+@xcode<   @b<subtype> Big_Real @b<is> Optional_Big_Real
+      @b<with> Dynamic_Predicate =@> Is_Valid (Big_Real),
+           Predicate_Failure =@> (@b<raise> Constraint_Error);>
+
+@xcode<   @b<function> "/" (Num, Den : Big_Integer) @b<return> Big_Real
+      @b<with> Pre =@> (@b<if> Big_Integers."=" (Den, 0)
+                   @b<then raise> Constraint_Error);>
+
+@xcode<   @b<function> Numerator (Arg : Big_Real) @b<return> Big_Integer;
+   @b<function> Denominator (Arg : Big_Real) @b<return> Big_Positive
+     @b<with> Post =@>
+       (Arg = 0.0) @b<or else>
+       (Big_Integers.Greatest_Common_Divisor
+          (Numerator (Arg), Denominator'Result) = 1);>
+
+@xcode<   @b<function> To_Big_Real (Arg : Big_Integer) @b<return> Big_Real @b<is>
+      (Arg / 1);>
+
+@xcode<   @b<function> To_Real (Arg : Integer) @b<return> Big_Real @b<is>
+      (Big_Integers.To_Big_Integer (Arg) / 1);>
+
+@xcode<   @b<function> "=" (L, R : Big_Real) @b<return> Boolean;
+   @b<function> "<" (L, R : Big_Real) @b<return> Boolean;
+   @b<function> "<=" (L, R : Big_Real) @b<return> Boolean;
+   @b<function> "@>" (L, R : Big_Real) @b<return> Boolean;
+   @b<function> "@>=" (L, R : Big_Real) @b<return> Boolean;>
+
+@xcode<   @b<function> In_Range (Arg, Low, High : Big_Real) @b<return> Boolean @b<is>
+     ((Low <= Arg) @b<and> (Arg <= High));>
+
+@xcode<   @b<generic>
+      @b<type> Num @b<is digits> <@>;
+   @b<package> Float_Conversions @b<is>
+      @b<function> To_Big_Real (Arg : Num) @b<return> Big_Real;
+      @b<function> From_Big_Real (Arg : Big_Real) @b<return> Num
+         @b<with> Pre =@> In_Range (Arg,
+                               Low  =@> To_Big_Real (Num'First),
+                               High =@> To_Big_Real (Num'Last))
+                     @b<or else> (@b<raise> Constraint_Error);
+   @b<end> Float_Conversions;>
+
+@xcode<   @b<generic>
+      @b<type> Num @b<is delta> <@>;
+   @b<package> Fixed_Conversions @b<is>
+      @b<function> To_Big_Real (Arg : Num) @b<return> Big_Real;
+      @b<function> From_Big_Real (Arg : Big_Real) @b<return> Num
+         @b<with> Pre =@> In_Range (Arg,
+                               Low  =@> To_Big_Real (Num'First),
+                               High =@> To_Big_Real (Num'Last))
+                     @b<or else> (@b<raise> Constraint_Error);
+   @b<end> Fixed_Conversions;>
+
+@xcode<   @b<function> To_String (Arg  : Big_Real;
+                       Fore : Field := 2;
+                       Aft  : Field := 3;
+                       Exp  : Field := 0) @b<return> String
+      @b<with> Post =@> To_String'Result'First = 1;
+   @b<function> From_String (Arg   : String) @b<return> Big_Real;>
+
+@xcode<   @b<function> To_Quotient_String (Arg : Big_Real) @b<return> String @b<is>
+      (To_String (Numerator (Arg)) & " / " & To_String (Denominator (Arg)));
+   @b<function> From_Quotient_String (Arg : String) @b<return> Big_Real;>
+
+@xcode<   @b<procedure> Put_Image
+     (Stream : @b<not null access> Ada.Streams.Root_Stream_Type'Class;
+      Arg    : Big_Real);>
+
+@xcode<   @b<function> "+" (L : Big_Real) @b<return> Big_Real;
+   @b<function> "-" (L : Big_Real) @b<return> Big_Real;
+   @b<function> "abs" (L : Big_Real) @b<return> Big_Real;
+   @b<function> "+" (L, R : Big_Real) @b<return> Big_Real;
+   @b<function> "-" (L, R : Big_Real) @b<return> Big_Real;
+   @b<function> "*" (L, R : Big_Real) @b<return> Big_Real;
+   @b<function> "/" (L, R : Big_Real) @b<return> Big_Real;
+   @b<function> "**" (L : Big_Real; R : Integer)
+      @b<return> Big_Real;
+   @b<function> Min (L, R : Big_Real) @b<return> Big_Real;
+   @b<function> Max (L, R : Big_Real) @b<return> Big_Real;>
+
+@xcode<@b<private>
+   ... -- @ft<@i<not specified by the language>>
+@b<end> Ada.Numerics.Big_Numbers.Big_Reals;>
+
+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
+interpretation of the Fore, Aft, and Exp parameters), except that
+Constraint_Error (not Data_Error) is propagated in error cases.
+From_Quotient_String implements the inverse function of To_Quotient_String;
+Constraint_Error is propagated in error cases. Put_Image calls To_String,
+converts that String to a Wide_Wide_String using To_Wide_Wide_String, and
+the resulting value to the stream using Wide_Wide_String'Write.
+
+For an instance of Float_Conversions or Fixed_Conversions, To_Big_Real
+is exact (that is, the result represents exactly the same
+mathematical value as the argument) and From_Big_Real is subject to
+the same precision rules as a type conversion of a value of type T to
+the target type Num, where T is a hypothetical floating point type whose
+model numbers include all of the model numbers of Num as well as the
+exact mathematical value of the argument.
+
+The other functions have their usual mathematical meanings.
+
+The type Optional_Big_Real needs finalization (see 7.6).
+
+@s8<@i<Implementation Requirements>>
+
+No storage associated with an Optional_Big_Real object shall be lost
+upon assignment or scope exit.
+
+For purposes of determining whether predicate checks are performed
+as part of default initialization, the type Optional_Big_Real
+shall be considered to have a subcomponent that has a @fa<default_expression>.
+
+
 !ASIS
 
 No ASIS effect (assuming this is ONLY a library).
@@ -6313,16 +6617,16 @@
 Sent: Friday, February  2, 2019   7:23 PM
 
 ...
-> 1) Fixed a "Numeerics" typo, as well as incorporating Randy's 
+> 1) Fixed a "Numeerics" typo, as well as incorporating Randy's
 > editorial
 >     fixes that he made when posting version #5 (hopefully I didn't
 >     miss any).
 
 I didn't see any editorial fixes missed. Good job!
- 
+
 However, you neither addressed nor dismissed my technical concerns over the
 11.5(23) wording. At a bare minimum, you need to adjust the wording to mention
-instances of these packages and drop the mention of Type_Invariants (since 
+instances of these packages and drop the mention of Type_Invariants (since
 they're treated like Post -- must be True or else). The "Reason"
 talks about the non-existent package "Ada.Big_Numbers".
 
@@ -6330,34 +6634,34 @@
 
 Numeric_Check
 
-Perform the checks associated with the Pre, Static_Predicate, or 
-Dynamic_Predicate aspects associated with an entity declared in a descendant 
+Perform the checks associated with the Pre, Static_Predicate, or
+Dynamic_Predicate aspects associated with an entity declared in a descendant
 unit of Numerics or in an instance of a generic unit that is declared in, or
 is, a descendant unit of Numerics.
 
-AARM Reason: One could use the Assertion_Policy to eliminate such checks, 
+AARM Reason: One could use the Assertion_Policy to eliminate such checks,
 but that would require recompiling the Ada.Numerics packages (the assertion
-policy that determines whether the checks are made is that used to compile 
-the unit). In addition, we do not want to specify the behavior of the 
-Ada.Numerics operations if a precondition or predicate fails; that is 
+policy that determines whether the checks are made is that used to compile
+the unit). In addition, we do not want to specify the behavior of the
+Ada.Numerics operations if a precondition or predicate fails; that is
 different than the usual behavior of Assertion_Policy.
-By using Suppress for this purpose, we make it clear that suppressing a 
+By using Suppress for this purpose, we make it clear that suppressing a
 check that would have failed results in erroneous execution.
 
 ----
 
-But this is way too big a change from me to make without concurrence from 
+But this is way too big a change from me to make without concurrence from
 others. In particular, I don't know if my "subsystem suppression" plan was
-really adopted by the group or if I just invented it and really only the 
+really adopted by the group or if I just invented it and really only the
 containers were approved. (BTW, I think it is likely that I will change the
-containers to use wording like the above, if we go forward with this; the 
-containers wording is more targeted to just Pre, as we can't add predicates 
+containers to use wording like the above, if we go forward with this; the
+containers wording is more targeted to just Pre, as we can't add predicates
 to existing packages. But I'd rather that each such check was described the
 same.)
 
 Below is the relevant part of my original message on this topic:
 
-[See the last part of Randy's message of January 8, 2019 7:56 PM 
+[See the last part of Randy's message of January 8, 2019 7:56 PM
 for this text - Editor.]
 
 ****************************************************************
@@ -6365,16 +6669,16 @@
 From: John Barnes
 Sent: Thursday, February  7, 2019   7:06 AM
 
-I have  been fretting about this topic for some time  with some restless 
+I have  been fretting about this topic for some time  with some restless
 nights.
 
-Please find attached some thoughts. I fear they are in Word rather than plain 
+Please find attached some thoughts. I fear they are in Word rather than plain
 text for typographical reasons.
 
 [Editor's note: These thoughts are found in the Grab-Bag on Ada-Auth.org:
   http://www.ada-auth.org/ai-files/grab_bag/literals.pdf  ]
 
-Jeff has helped me with getting  my thoughts in order for which I am most 
+Jeff has helped me with getting  my thoughts in order for which I am most
 grateful.
 
 I also have a problem with being very busy with a course at Oxford this term.
@@ -6384,47 +6688,47 @@
 From: Randy Brukardt
 Sent: Thursday, February  7, 2019   7:45 PM
 
->I have  been fretting about this topic for some time - with some 
+>I have  been fretting about this topic for some time - with some
 >restless nights.
 
-I'm the only one that's allowed to have sleepless nights over unimportant Ada 
+I'm the only one that's allowed to have sleepless nights over unimportant Ada
 issues. ;-)
 
->Please find attached some thoughts. 
+>Please find attached some thoughts.
 
 [Some thoughts quoted below...]
 
-> So what to do. Well maybe change AI-249 to provide only one literal 
-> and please call it just Literal and change the !subject of the AI to 
+> So what to do. Well maybe change AI-249 to provide only one literal
+> and please call it just Literal and change the !subject of the AI to
 > "User-defined literals".
 
-The problem with this is that there are three other kinds of user-defined 
-literals defined in other AIs. We adopted the string literal AI as well (left 
-the character and null literals for the future, since uses of those are a 
+The problem with this is that there are three other kinds of user-defined
+literals defined in other AIs. We adopted the string literal AI as well (left
+the character and null literals for the future, since uses of those are a
 stretch).
 
-Merging real and integer literals also has the very significant downside of 
-changing a compile-time error into an exception raised in the case of 
-operations that only want integer literals (like Big_Integer). If 
+Merging real and integer literals also has the very significant downside of
+changing a compile-time error into an exception raised in the case of
+operations that only want integer literals (like Big_Integer). If
    Int : Big_Integer := 3.14;
 is legal but raises an exception at runtime, we've lost something significant.
 
->I think that if AI-249 defines aspects for Real_Literal and 
+>I think that if AI-249 defines aspects for Real_Literal and
 >Integer_Literal
 
 >then it ought to say exactly what they are.
 
-They correspond to a use of the corresponding lexical construct. This is 
+They correspond to a use of the corresponding lexical construct. This is
 described in the Dynamic Semantics of each aspect (see 4.2.1 in the draft
 RM):
 
   For the evaluation of an integer (or real) literal with expected type
   having an Integer_Literal (or Real_Literal) aspect specified ...
 
-There might be a clearer way to state this in the wording, and especially in 
+There might be a clearer way to state this in the wording, and especially in
 the AI presentation, but that's the point of editorial review.
 
-One thing that immediately stands out to me is that it isn't clear that this 
+One thing that immediately stands out to me is that it isn't clear that this
 is really two separate rules:
 
   For the evaluation of an integer literal with expected type having an
@@ -6435,88 +6739,88 @@
   For the evaluation of a real literal with expected type having a Real_Literal
   aspect specified ...
 
-Tucker tried to save some wording here, but I don't think the result is 
-particularly clear (one could easily read these as one single rule, from your 
-various gripes it appears that you did that), and two shorter sentences (even 
+Tucker tried to save some wording here, but I don't think the result is
+particularly clear (one could easily read these as one single rule, from your
+various gripes it appears that you did that), and two shorter sentences (even
 if very repetitive) would be better than one longer one.
 
 This seems like a clear editorial review correction, if you want to request it.
 
 >Remember also that a key goal of Ada has always been that programs should
->be easy to maintain by someone other than the author. Perhaps we need some 
+>be easy to maintain by someone other than the author. Perhaps we need some
 >mark to indicate that the literal has come via an aspect.
 
-No, that would destroy the purpose (to make the use of user-defined types the 
+No, that would destroy the purpose (to make the use of user-defined types the
 same as the use of built-in types). Ideally, one would get rid of the built-in
-types altogether and define everything in packages using these aspects 
+types altogether and define everything in packages using these aspects
 (literals, indexing, de-reference, iterators, and so on).
 
 >We might write
 >   BI: Big_Integer := [-123456];
 
 The thing is square brackets is an array/container aggregate in Ada 2020.
-Supporting this syntax for literals would destroy the critical reason for 
-introducing the square bracket syntax for aggregates in the first place: the 
+Supporting this syntax for literals would destroy the critical reason for
+introducing the square bracket syntax for aggregates in the first place: the
 ability to write single-valued aggregates in a natural way.
 
 So you need a different syntax.
 
 ...
 
-> 1. Do nothing, leave it as it is. There is a risk that old John will 
-> resign from the ARG and not review anything else ever, ever! A bit 
-> unlikely since one supposes that he has to update his book. But he is 
+> 1. Do nothing, leave it as it is. There is a risk that old John will
+> resign from the ARG and not review anything else ever, ever! A bit
+> unlikely since one supposes that he has to update his book. But he is
 > very grumpy.
 
 I don't think we will leave it *exactly* as it is, but I don't think there are
-going to be major changes. I had some other thoughts, but they are best kept 
+going to be major changes. I had some other thoughts, but they are best kept
 to myself. :-)
 
-> 3. Do something more exciting as outlined above. But at least get rid 
-> of the Real_Literal and Integer_Literal aspects. Make it just Literal. 
-> Or if you must keep them, define exactly what the literal form is and 
-> provide a third aspect Literal for the ambitious user. Or maybe give 
+> 3. Do something more exciting as outlined above. But at least get rid
+> of the Real_Literal and Integer_Literal aspects. Make it just Literal.
+> Or if you must keep them, define exactly what the literal form is and
+> provide a third aspect Literal for the ambitious user. Or maybe give
 > the user the ability to add aspects so that Rational_Literal can be added.
 
-The reason for Real_Literal and Integer_Literal being separate was discussed 
-above. There is a third aspect, String_Literal (see AI12-0295-1, which you 
-haven't reviewed yet). It was split out because people wanted to vote 
+The reason for Real_Literal and Integer_Literal being separate was discussed
+above. There is a third aspect, String_Literal (see AI12-0295-1, which you
+haven't reviewed yet). It was split out because people wanted to vote
 separately on the different aspects.
 
-Since these things are tied to the lexical structure of the program, adding 
-something more is complicated. And it is likely that an ambitious user could 
+Since these things are tied to the lexical structure of the program, adding
+something more is complicated. And it is likely that an ambitious user could
 use String_Literal for the sorts of suggestions that you have.
 
-> 4. Do not confuse rational numbers with a means of providing highly 
+> 4. Do not confuse rational numbers with a means of providing highly
 > accurate real arithmetic. Define Big_Float or Big_Real. Preferably
 Big_Real.
 
-Ah, here we have an actionable suggestion. One has to use rational numbers to 
-*implement* accurate real arithmetic, but one does not have to *present* it 
+Ah, here we have an actionable suggestion. One has to use rational numbers to
+*implement* accurate real arithmetic, but one does not have to *present* it
 that way.
 
-Would you be happier if we renamed the current package and types to "Big_Real" 
-(no other changes)? This a change I could get behind, as I don't think anyone 
-really wants rational numbers (certainly not enough people to justify a 
-standard package), but lots of people want more accurate real numbers. Our 
-compiler's package calls these things "Univ_Real" (short for universal_real); 
+Would you be happier if we renamed the current package and types to "Big_Real"
+(no other changes)? This a change I could get behind, as I don't think anyone
+really wants rational numbers (certainly not enough people to justify a
+standard package), but lots of people want more accurate real numbers. Our
+compiler's package calls these things "Univ_Real" (short for universal_real);
 there's no sign of rational until you look under the covers.
 
->To provide rationals is so easy that it hardly merits being in the language. 
+>To provide rationals is so easy that it hardly merits being in the language.
 >But if it is, provide it as a separate item and do it properly.
 
-It's not remotely easy (to do correctly and efficiently). One has to reduce 
-the rationals frequently in order to avoid unbounded memory usage -- but you 
-can't do that after every operation because it is too expensive. In any case, 
+It's not remotely easy (to do correctly and efficiently). One has to reduce
+the rationals frequently in order to avoid unbounded memory usage -- but you
+can't do that after every operation because it is too expensive. In any case,
 rationals are a rare need that doesn't need to be in the language per-se.
 
-Of course, someone could use the "Big_Real" package for rational math, (the 
+Of course, someone could use the "Big_Real" package for rational math, (the
 operations still all being there) but it wouldn't be presented that way.
 
->Whatever is done, correct the phrase arbitrary-precision rationals from A.5.5. 
+>Whatever is done, correct the phrase arbitrary-precision rationals from A.5.5.
 >Rationals are always precise.
 
-Should say "arbitrary-precision reals", of course. That's what people 
+Should say "arbitrary-precision reals", of course. That's what people
 want/understand.
 
 ****************************************************************
@@ -6524,24 +6828,24 @@
 From: Tucker Taft
 Sent: Thursday, February  7, 2019   9:05 PM
 
-I understand some of your concerns, John, but I also have experience with 
-supporting the use literals with user-defined types much as we have proposed, 
-and it is extremely valuable.  I also think the use of the term "Big_Rational" 
-has set you on edge, and I would agree with Randy that we should change these 
-to "Big_Real" to avoid the confusion.  If they are really viewed externally 
-as rationals, then you are right that the correct syntax for defining one 
-would be "N / M" where N and M are integer literals.  Instead, they are 
-intended to be used for arbitrary-precision real values, as is needed, say, 
+I understand some of your concerns, John, but I also have experience with
+supporting the use literals with user-defined types much as we have proposed,
+and it is extremely valuable.  I also think the use of the term "Big_Rational"
+has set you on edge, and I would agree with Randy that we should change these
+to "Big_Real" to avoid the confusion.  If they are really viewed externally
+as rationals, then you are right that the correct syntax for defining one
+would be "N / M" where N and M are integer literals.  Instead, they are
+intended to be used for arbitrary-precision real values, as is needed, say,
 for your average Ada compiler front end.
 
-The point of AI-249 is not to support odd-ball syntaxes for literals, but 
-rather to allow the *existing* syntax for numeric literals to be used with 
-private types.  If the AI made you think that users were being given the 
-opportunity to invent some new kind of syntax for literals, it definitely 
-needs to be clarified.  The first thing to change is the !subject -- instead 
-of "user-defined numeric literals" it should be "numeric literals for 
-user-defined types."  And we should use that terminology throughout, rather 
-than ever saying "user-defined literals."  We really are not supporting that 
+The point of AI-249 is not to support odd-ball syntaxes for literals, but
+rather to allow the *existing* syntax for numeric literals to be used with
+private types.  If the AI made you think that users were being given the
+opportunity to invent some new kind of syntax for literals, it definitely
+needs to be clarified.  The first thing to change is the !subject -- instead
+of "user-defined numeric literals" it should be "numeric literals for
+user-defined types."  And we should use that terminology throughout, rather
+than ever saying "user-defined literals."  We really are not supporting that
 in this AI.
 
 ****************************************************************
@@ -6549,16 +6853,16 @@
 From: John Barnes
 Sent: Tuesday, February 12, 2019   9:27 AM
 
-Changing the title of 249 as you suggest would help a lot. I completely 
+Changing the title of 249 as you suggest would help a lot. I completely
 misunderstood the purpose.
 
-And making it Big_Real would be excellent. Don't call them rationals 
+And making it Big_Real would be excellent. Don't call them rationals
 externally. That was the big mistake which as you say set me on edge.
 
-Make such changes and then  I can go to my grave in peace.  (well apart from 
+Make such changes and then  I can go to my grave in peace.  (well apart from
 anonymous access types of course)
 
-So at the bottom of the problem is that the rationale for these AIs was not 
+So at the bottom of the problem is that the rationale for these AIs was not
 clearly stated.
 
 ****************************************************************
@@ -6576,7 +6880,7 @@
     X := 1/3;
 
 where X is a Big_Rat.  And you CAN say that.  I don't see why it makes any
-difference that the RM doesn't call that notation a "literal".  You can 
+difference that the RM doesn't call that notation a "literal".  You can
 think of it as a "literal" notation if you like.
 
 ****************************************************************
@@ -6587,8 +6891,8 @@
 > Why on earth would we call something a "real"
 > if it can't represent irrational numbers such as square root of 2?
 
-Because since FORTRAN-2, it is a tradition to have the false advertisement 
-of calling "Real" a finite number of values from a bounded segment of the 
+Because since FORTRAN-2, it is a tradition to have the false advertisement
+of calling "Real" a finite number of values from a bounded segment of the
 rationals...
 
 ****************************************************************
@@ -6597,24 +6901,24 @@
 Sent: Tuesday, February 12, 2019   11:25 AM
 
 >> And making it Big_Real would be excellent.
-> 
+>
 > Why on earth would we call something a "real"
 > if it can't represent irrational numbers such as square root of 2?
 
 Well Ada has "universal-real" and it has the same problem.  In the context
-of Ada, I think Big_Real would be a reasonable name.  I agree in a wider 
+of Ada, I think Big_Real would be a reasonable name.  I agree in a wider
 context, it could be misleading.
 
 > As for literals, you want to be able to say things like:
-> 
+>
 >    X := 1/3;
-> 
-> where X is a Big_Rat.  And you CAN say that.  I don't see why it makes 
-> any difference that the RM doesn't call that notation a "literal".  
+>
+> where X is a Big_Rat.  And you CAN say that.  I don't see why it makes
+> any difference that the RM doesn't call that notation a "literal".
 > You can think of it as a "literal" notation if you like.
 
-It is worth pointing out that we do include in the "big-num" AI a "/" operator 
-that takes two (big) integers and produces a Big_R...  We also have a "/" that 
+It is worth pointing out that we do include in the "big-num" AI a "/" operator
+that takes two (big) integers and produces a Big_R...  We also have a "/" that
 takes 2 Big_Rs and produces another Big_R.
 
 ****************************************************************
@@ -6624,20 +6928,20 @@
 
 > Why on earth would we call something a "real"
 > if it can't represent irrational numbers such as square root of 2?
-> 
+>
 > As for literals, you want to be able to say things like:
-> 
+>
 >      X := 1/3;
-> 
-> where X is a Big_Rat.  And you CAN say that.  I don't see why it makes 
-> any difference that the RM doesn't call that notation a "literal".  
+>
+> where X is a Big_Rat.  And you CAN say that.  I don't see why it makes
+> any difference that the RM doesn't call that notation a "literal".
 > You can think of it as a "literal" notation if you like.
 
 I agree with Bob.
 
 And don't forget that we have
    function Numerator (Arg : Big_Rational) return Big_Integer;
-   function Denominator (Arg : Big_Rational) return Big_Positive ... ; which, 
+   function Denominator (Arg : Big_Rational) return Big_Positive ... ; which,
 to me, strongly suggests that we are talking about rationals here.
 
 ****************************************************************
@@ -6645,34 +6949,34 @@
 From: Randy Brukardt
 Sent: Tuesday, February 12, 2019   3:15 PM
 
-You are confusing implementation with intended use. Conservatively, 95% of 
-users of this package are interested in getting exact real math, as in static 
-universal real calculations. They probably care little about the 
-implementation technique. I know I find the use of rationals in our universal 
-math package more annoying that useful. For that large subset of users, they 
+You are confusing implementation with intended use. Conservatively, 95% of
+users of this package are interested in getting exact real math, as in static
+universal real calculations. They probably care little about the
+implementation technique. I know I find the use of rationals in our universal
+math package more annoying that useful. For that large subset of users, they
 want "Big_Real" and could care less about rational anything.
 
-Note that Big_Real usage is the justification for supporting real literals 
-with the package. I agree with John in the sense that 0.0 makes no sense as a 
-rational number. But of course it is completely sensible for a Big_Real 
+Note that Big_Real usage is the justification for supporting real literals
+with the package. I agree with John in the sense that 0.0 makes no sense as a
+rational number. But of course it is completely sensible for a Big_Real
 number.
 
-The number of users that actually would want a rational number package is 
+The number of users that actually would want a rational number package is
 small enough that we couldn't justify spending any time on standardizing it.
 
-It would make perfect sense to scrub this package of the operations which 
+It would make perfect sense to scrub this package of the operations which
 expose a rational implementation, and literally make it a Big_Real package.
-But the implementation still would have to be using rationals. 
+But the implementation still would have to be using rationals.
 
-There's no need to expose the rational implementation for most users, but it's 
-also harmless to do so for that <5% that actually care for some reason (and it 
-adds a bit of utility to the package). It's very much like Claw in this 
-regard: Claw has a handle interface which lets one access the underlying 
-Windows handles. But hardly anyone should ever need that (I've never used it, 
+There's no need to expose the rational implementation for most users, but it's
+also harmless to do so for that <5% that actually care for some reason (and it
+adds a bit of utility to the package). It's very much like Claw in this
+regard: Claw has a handle interface which lets one access the underlying
+Windows handles. But hardly anyone should ever need that (I've never used it,
 for instance); it just exists for that rare user that has a need.
 
-One thing I would suggest is to place any of the operations that expose the 
-implementation dead last in the package (there shouldn't be many), so that the 
+One thing I would suggest is to place any of the operations that expose the
+implementation dead last in the package (there shouldn't be many), so that the
 typical user doesn't have to wade through irrelevant junk to get to the meat.
 
 ****************************************************************
@@ -6680,15 +6984,109 @@
 From: Steve Baird
 Sent: Tuesday, February 12, 2019   6:13 PM
 
-> Well Ada has "universal-real" and it has the same problem.  In the context 
+> Well Ada has "universal-real" and it has the same problem.  In the context
 > of Ada, I think Big_Real would be a reasonable name.
 
-I'd still prefer Big_Rational, but I agree that what you are saying makes 
+I'd still prefer Big_Rational, but I agree that what you are saying makes
 sense.
 
-Ada, for example, defines a type Integer rather than Bounded_Integer even 
+Ada, for example, defines a type Integer rather than Bounded_Integer even
 though the notion of Integer'Last is mathematically somewhat dubious.
 
 I can live with Big_Real.
+
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Wednesday, February 13, 2019   2:47 AM
+
+> One thing I would suggest is to place any of the operations that 
+> expose the implementation dead last in the package (there shouldn't be 
+> many), so that the typical user doesn't have to wade through 
+> irrelevant junk to get to the meat.
+
+Why not put these operations in a child package (with an implementation 
+permission to not provide them if the implementation does not use a rational 
+implementation)?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, March 15, 2019   8:31 PM
+
+I'm working on putting this AI into the draft RM, and so of course I'm seeing
+some glitches. Nothing very substantive, so this is essentially a 
+for-the-record note:
+
+(1) The lead-ins for the packages read:
+
+The package Ada.Numerics.Big_Numbers has the following declaration:
+
+However, these usually say "*library* package" and they omit the "Ada.", giving:
+
+The library package Numerics.Big_Numbers has the following declaration:
+
+(2) Thou shall not use "i.e.":
+
+For an instance of Float_Conversions or Fixed_Conversions, To_Big_Real is 
+exact (i.e., the result represents exactly the same ...
+
+so replaced that by "that is"
+
+For an instance of Float_Conversions or Fixed_Conversions, To_Big_Real is 
+exact (that is, the result represents exactly the same ...
+
+(3) The Post for Denominator reads:
+
+   with Post =>
+      (Arg = 0.0) or else
+      (Greatest_Common_Divisor
+         (Numerator (Arg), Denominator'Result) = 1);
+
+but there is no Greatest_Common_Divisor in this package. It seems that when 
+someone (that would have been me) suggested removing a confusing and barely 
+used use clause, they missed one of the places it was (ahem) used. So this 
+should be:
+
+   with Post =>
+      (Arg = 0.0) or else
+      (Big_Integers.Greatest_Common_Divisor
+         (Numerator (Arg), Denominator'Result) = 1);
+
+(4) We have:
+
+The type Optional_Big_Integer requires finalization.
+
+but the term is "needs finalization", and we usually put a cross-reference by 
+it to make it clearer that this is a term and formal definition. So this 
+should be:
+
+The type Optional_Big_Integer needs finalization (see 7.6).
+
+Also, this statement is missing for Optional_Big_Real, even though the 
+expected implementation is of two components of Optional_Big_Integer.
+
+(5) Since we swapped the parameters of S'Put_Image, we better do that for the 
+routine intended to implement that aspect. (Once in each package.)
+
+(6) To_Integer reads:
+
+      function To_Integer (Arg : Big_Integer) return Integer
+        with Pre => In_Range (Arg,
+                              Low => +Integer'First,
+                              High => +Integer'Last)
+                    or else (raise Constraint_Error);
+
+but we (ahem) deleted the overloaded "+" in the last revision. We probably 
+ought not use it here. ;-)
+
+So this should read:
+
+      function To_Integer (Arg : Big_Integer) return Integer
+        with Pre => In_Range (Arg,
+                              Low  => To_Big_Integer (Integer'First),
+                              High => To_Big_Integer (Integer'Last))
+                    or else (raise Constraint_Error);
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent