--- 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