--- ai12s/ai12-0208-1.txt 2019/01/09 02:21:19 1.17 +++ ai12s/ai12-0208-1.txt 2019/02/02 01:14:04 1.18 @@ -1,4 +1,4 @@ -!standard A.5.5(0) 19-01-07 AI12-0208-1/07 +!standard A.5.5(0) 19-02-01 AI12-0208-1/08 !standard A.5.6(0) !standard A.5.7(0) !standard A.5.8(0) @@ -60,9 +60,24 @@ with Dynamic_Predicate => Is_Present (Big_Integer), Predicate_Failure => (raise Constraint_Error); - function Invalid return Optional_Big_Integer - with Post => not Is_Present (Invalid'Result); + function No_Big_Integer return Optional_Big_Integer + with Post => not Is_Present (No_Big_Integer'Result); + [TBD: Tuck does not like the names Is_Present and Null_Big_Integer + (and similarly for Is_Present and Null_Big_Rational). I don't know + how Tuck feels about No_Big_Integer (as opposed to Null_Big_Integer). + In private communication with Steve, the following alternatives were + discussed: + 1) Is_Null and Null_Big_Integer + 2) Augment #1 with a Not_Null function (i.e. provide both polarities, + like "=" and "/="). + 3) Is_Valid and Invalid_Big_Integer. + 4) Is_Defined and Undefined_Big_Integer. + 5) Is_Present and Null_Big_Integer. + 6) Is_Present and No_Big_Integer (as in the current proposal). + We may need a straw poll to settle this one.] + + function "=" (L, R : Big_Integer) return Boolean; function "<" (L, R : Big_Integer) return Boolean; function "<=" (L, R : Big_Integer) return Boolean; @@ -74,11 +89,13 @@ renames To_Big_Integer; subtype Optional_Big_Positive is Optional_Big_Integer - with Dynamic_Predicate => Optional_Big_Positive > 0, + with Dynamic_Predicate => (not Is_Present (Optional_Big_Positive)) + or else (Optional_Big_Positive > 0), Predicate_Failure => (raise Constraint_Error); subtype Optional_Big_Natural is Optional_Big_Integer - with Dynamic_Predicate => Optional_Big_Natural >= 0, + with Dynamic_Predicate => (not Is_Present (Optional_Big_Natural)) + or else (Optional_Big_Natural >= 0), Predicate_Failure => (raise Constraint_Error); subtype Big_Positive is Big_Integer @@ -171,6 +188,9 @@ No storage associated with an Optional_Big_Integer object shall be lost upon assignment or scope exit. + AARM note: The "No storage ... shall be lost" requirement does not preclude + implementation techniques such as caching or unique number tables. + 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 default_expression. @@ -178,85 +198,8 @@ AARM Note: This means that the elaboration of Default_Initialized_Object : Big_Integer; is required to propagate Assertion_Error. - -A.5.7 Bounded Big Integers - -An instance of the language-defined generic package -Numerics.Big_Numbers.Bounded_Big_Integers provides an Optional_Big_Integer -type and operations corresponding to those declared in -Numerics.Big_Numbers.Big_Integers, but with the difference that the maximum -storage (and, consequently, the set of representable values) is bounded. - -The declaration of the generic library package -Numerics.Big_Numbers.Bounded_Big_Integers has the same contents and semantics as -Numerics.Big_Numbers.Big_Integers except: - - - Bounded_Big_Integers is a generic package and takes a generic formal: - Capacity : Natural; - - - two additional visible expression functions are declared: - function Last return Big_Integer is ((+256) ** Capacity); - function First return Big_Integer is (-Last); - - - the partial view of Bounded_Big_Integers.Optional_Big_Integer includes - a type invariant specification, - Type_Invariant => - (if Is_Present (Optional_Big_Integer) then - In_Range (Optional_Big_Integer, First, Last) - or else (raise Constraint_Error)) - [TBD: instead express this as a Dynamic_Predicate? If so, on - Optional_Big_Integer or on Big_Integer?] - -Each subprogram of an instance of -Numerics.Big_Numbers.Bounded_Big_Integers -behaves like the corresponding Numerics.Big_Numbers.Big_Integers subprogram -except that type invariant checks are performed as described in 7.3.2. - -The type Optional_Big_Integer declared by an instance of Bounded_Big_Integers -does not require finalization. - -Implementation Requirements - -For each instance of Bounded_Big_Integers, the output generated by -Optional_Big_Integer'Output or Optional_Big_Integer'Write shall be -readable by the -corresponding Input or Read operations of the Optional_Big_Integer type -declared in either another instance of Bounded_Big_Integers or in -the package Numerics.Big_Numbers.Big_Integers. [This is subject to the -preceding requirement that type invariant checks are performed, so -that Constraint_Error may be raised in some cases.] - -Implementation Advice - -The implementation of (an instance of) Bounded_Big_Integers should not -make use of controlled types or dynamic allocation. - -[end of Implementation Advice] - -The generic unit Numerics.Big_Numbers.Conversions -provides operations for converting between the Big_Integer types declared -in Numerics.Big_Numbers.Big_Integers and in an instance of -Numeerics.Big_Numbers.Bounded_Big_Integers. - -The generic package Numerics.Big_Numbers.Conversions has the -following declaration: - - with Ada.Numerics.Big_Numbers.Big_Integers; - with Ada.Numerics.Big_Numbers.Bounded_Big_Integers; - generic - with package Bounded is new Bounded_Big_Integers (<>); - package Ada.Numerics.Big_Numbers.Conversions - with Preelaborate, Nonblocking - is - function To_Bounded - (Arg : Big_Integers.Big_Integer) - return Bounded.Big_Integer; - function From_Bounded - (Arg : Bounded.Big_Integer) - return Big_Integers.Big_Integer; - end Ada.Numerics.Big_Numbers.Conversions; -A.5.8 Big Rationals +A.5.7 Big Rationals The package Numerics.Big_Numbers.Big_Rationals has the following declaration: @@ -275,8 +218,8 @@ function Is_Present (Arg : Optional_Big_Rational) return Boolean; - function Invalid return Optional_Big_Rational - with Post => not Is_Present (Invalid'Result); + function No_Big_Rational return Optional_Big_Rational + with Post => not Is_Present (No_Big_Rational'Result); subtype Big_Rational is Optional_Big_Rational with Dynamic_Predicate => Is_Present (Big_Rational), @@ -354,7 +297,7 @@ function "-" (L, R : Big_Rational) return Big_Rational; function "*" (L, R : Big_Rational) return Big_Rational; function "/" (L, R : Big_Rational) return Big_Rational; - function "**" (L : Big_Rational; R : Big_Integer) + function "**" (L : Big_Rational; R : Integer) return Big_Rational; function Min (L, R : Big_Rational) return Big_Rational; function Max (L, R : Big_Rational) return Big_Rational; @@ -379,21 +322,15 @@ model numbers include all of the model numbers of Num as well as the exact mathematical value of the argument. -[TBD: Is Constraint_Error the exception we want on the Predicate_Failure -aspect specs for Big_Integer and Big_Rational?] -[TBD: the range check on From_Big_Rational is slightly too tight. -For example, - X : IEEE_Float32 := - IEEE_Float32 (IEEE_Float64'Succ (IEEE_Float64 (IEEE_Float32'Last))); -does not overflow but the corresponding conversion using From_Big_Rational -would fail the range check. Do we care?] - The other functions have their usual mathematical meanings. Implementation Requirements No storage associated with an Optional_Big_Rational object shall be lost upon assignment or scope exit. + AARM note: The "No storage ... shall be lost" requirement does not preclude + implementation techniques such as caching or unique number tables. + For purposes of determining whether predicate checks are performed as part of default initialization, the type Optional_Big_Rational shall be considered to have a subcomponent that has a default_expression. @@ -402,8 +339,6 @@ Default_Initialized_Object : Big_Rational; is required to propagate Assertion_Error. -AARM Note: No Bounded_Big_Rationals generic package is provided. - ==== This section, or at least the AARM note, is intended to follow @@ -418,10 +353,6 @@ or Type_Invariant aspect specifications occuring in the visible part of package Numerics.Big_Numbers or of any of its descendants. -[TBD: Include Static_Predicate in this list just for completeness, even -though it happens that there are no Static_Predicate specifications in -these units?] - AARM Reason: One could use the Assertion_Policy to eliminate such checks, but that would require recompiling the Ada.Big_Numbers packages (the assertion policy that determines whether the checks are made is that @@ -5792,15 +5723,15 @@ From: Steve Baird Sent: Monday, January 7, 2018 2:51 PM - -The attached version #5 of this AI [Regardless of what this message says, -this is version /07 of this AI - Editor] is intended to address + +The attached version #5 of this AI [Regardless of what this message says, +this is version /07 of this AI - Editor] is intended to address issues/questions raised since distribution of version #4 on 12/2/18. -Thanks, in particular, to Bob and Randy for their careful review and +Thanks, in particular, to Bob and Randy for their careful review and thoughtful comments. -A summary of those issues/questions, along with their proposed resolutions, +A summary of those issues/questions, along with their proposed resolutions, follows below. ==== @@ -5822,15 +5753,15 @@ Is_Valid => Is_Present (and similarly for Big_Rational) and add Optional_Big_Natural, Optional_Big_Positive subtypes. -Yes; change is in version 5. The Is_Valid -> Is_Present substitution wasn't -mentioned in the discussion, but it seems obvious now that we are no longer +Yes; change is in version 5. The Is_Valid -> Is_Present substitution wasn't +mentioned in the discussion, but it seems obvious now that we are no longer talking about validity. 5) Add a Big_Int -> Big_Rational conversion function? Similarly, add a Big_Rat exponentiation operator that takes a Big_Integer instead of an Integer for the exponent argument? Further discussion is needed here. -There are changes in version 5 for this, but they are not what was +There are changes in version 5 for this, but they are not what was requested. The problem (which was not mentioned in the original discussion) is to avoid introducing ambiguity in the case of a call @@ -5879,21 +5810,21 @@ "1 / 1" might be preferable to something like "999999999999999999999999999998 / 999999999999999999999999999999". This sounds like a good idea, but it is not clear what the spec should -look like. One idea is a Round_To_Nearest_Multiple function, where the +look like. One idea is a Round_To_Nearest_Multiple function, where the user passes in a delta value (a positive big_rational) and the function -returns a result which is an exact integral multiple of that delta value +returns a result which is an exact integral multiple of that delta value (with tiebreaker rules based on Ada's rules for converting to a fixed point type). Another idea is a Best_Approximation function where the user passes in a denominator value (a positive big_integer) and the function computes the closest continued fraction approximation having a denominator no greater than the specified denominator value. It would be nice to simply require that the function returns the closest -approximation to the given argument subject to the denominator +approximation to the given argument subject to the denominator constraint, but I don't know how to implement that. [It has to do with not just computing convergents, but also semi-convergents; for more details, see the site I mentioned in a message to the ARG list last January, - + shreevatsa.wordpress.com/2011/01/10/not-all-best-rational-approximations-are-the-convergents-of-the-continued-fraction ].It does seem clear that the function, however it is defined, should be portable. I'm leaning toward the Round_To_Nearest_Multiple @@ -6023,22 +5954,22 @@ Sent: Monday, January 7, 2018 3:13 PM > 5) ... -> -> In the case of exponentiation, choosing a name other than "**" would -> defeat the whole point, so we just give up and don't provide a version -> that takes a Standard.Integer exponent (we only provide the -> Big_Integer exponent version - in version #4, only a Standard.Integer -> exponent version was provided, but if we are only going to provide one +> +> In the case of exponentiation, choosing a name other than "**" would +> defeat the whole point, so we just give up and don't provide a version +> that takes a Standard.Integer exponent (we only provide the +> Big_Integer exponent version - in version #4, only a Standard.Integer +> exponent version was provided, but if we are only going to provide one > then shouldn't it be the Big_Integer version?).... -I think exponentiation is really a special case, and Standard.Integer should -be the exponent for X ** <int>. Even for user-defined integer types, the -exponent is still Standard.Integer. It is inconceivable that we could +I think exponentiation is really a special case, and Standard.Integer should +be the exponent for X ** <int>. Even for user-defined integer types, the +exponent is still Standard.Integer. It is inconceivable that we could represent values with exponents larger than Integer'Last unless the base is -0, 1, or -1. +0, 1, or -1. -As a fall-back for those really interested in Aleph-1-sized values (and with -appropriate amount of memory to go with it ;-), presumably you could use +As a fall-back for those really interested in Aleph-1-sized values (and with +appropriate amount of memory to go with it ;-), presumably you could use Big_Rat ** Big_Rat, and then convert the result to Big_Int. **************************************************************** @@ -6046,14 +5977,14 @@ From: Steve Baird Sent: Monday, January 7, 2018 5:02 PM -> I think exponentiation is really a special case, and Standard.Integer +> I think exponentiation is really a special case, and Standard.Integer > should be the exponent for X ** <int>. ... -> It is inconceivable that we could represent values with exponents +> It is inconceivable that we could represent values with exponents > larger than Integer'Last unless -Fine with me, as long as you promise not to complain the next time you want -to estimate the number of possible orderings of the atoms in the known +Fine with me, as long as you promise not to complain the next time you want +to estimate the number of possible orderings of the atoms in the known universe. **************************************************************** @@ -6061,7 +5992,7 @@ From: Randy Brukardt Sent: Monday, January 7, 2018 5:16 PM -Remember that Ada only requires Integer'Last >= 32767, and 2 ** 32768 isn't +Remember that Ada only requires Integer'Last >= 32767, and 2 ** 32768 isn't completely impossible. **************************************************************** @@ -6082,22 +6013,22 @@ > Is_Valid => Is_Present > (and similarly for Big_Rational) > and add Optional_Big_Natural, Optional_Big_Positive subtypes. -> Yes; change is in version 5. The Is_Valid -> Is_Present substitution -> wasn't mentioned in the discussion, but it seems obvious now that we +> Yes; change is in version 5. The Is_Valid -> Is_Present substitution +> wasn't mentioned in the discussion, but it seems obvious now that we > are no longer talking about validity. -I will say I am not in love with "Is_Present" as a way to check whether an -Optional_Integer has been initialized. I think the name of the constant -representing the default value of an Optional_integer (in this case, still -"Invalid") should determine the name of the query function. So I would stick +I will say I am not in love with "Is_Present" as a way to check whether an +Optional_Integer has been initialized. I think the name of the constant +representing the default value of an Optional_integer (in this case, still +"Invalid") should determine the name of the query function. So I would stick with "Is_Valid" if the named constant is "Invalid." If we change the constant -to be named something else, such as "Null_Big_Integer" then "Not_Null" and +to be named something else, such as "Null_Big_Integer" then "Not_Null" and "Is_Null" would be nice query functions. -In general, I don't think of an "Optional_Integer" as being optionally -"present," but rather being optionally "initialized." But in any case, I +In general, I don't think of an "Optional_Integer" as being optionally +"present," but rather being optionally "initialized." But in any case, I think the name of the constant and the name of the query should be aligned. -We could name the constant "Absent_Integer" I suppose, but that just seems +We could name the constant "Absent_Integer" I suppose, but that just seems weird. ;-) **************************************************************** @@ -6108,12 +6039,12 @@ > So I would stick with "Is_Valid" if the named constant is "Invalid." -That was an oversight on my part. I intended to remove all references to -validity but forgot about Invalid (which, incidentally, is defined as a -parameterless function). I'd say those functions should be named +That was an oversight on my part. I intended to remove all references to +validity but forgot about Invalid (which, incidentally, is defined as a +parameterless function). I'd say those functions should be named Null_Big_Integer and Null_Big_Rational. -And I certainly agree with you about the undesirable inconsistency of +And I certainly agree with you about the undesirable inconsistency of Is_Present and Invalid. **************************************************************** @@ -6123,12 +6054,12 @@ >> So I would stick with "Is_Valid" if the named constant is "Invalid." -> That was an oversight on my part. I intended to remove all references -> to validity but forgot about Invalid (which, incidentally, is defined -> as a parameterless function). I'd say those functions should be named +> That was an oversight on my part. I intended to remove all references +> to validity but forgot about Invalid (which, incidentally, is defined +> as a parameterless function). I'd say those functions should be named > Null_Big_Integer and Null_Big_Rational. -Then I would argue for providing Not_Null and perhaps also Is_Null as +Then I would argue for providing Not_Null and perhaps also Is_Null as query functions, rather than Is_Present. **************************************************************** @@ -6136,10 +6067,10 @@ From: Randy Brukardt Sent: Tuesday, January 8, 2018 8:12 PM -> I'd say those functions should be named +> I'd say those functions should be named > Null_Big_Integer and Null_Big_Rational. -Gee, if we hadn't deferred the Null_Literal aspect (now, AI12-0296-1), you +Gee, if we hadn't deferred the Null_Literal aspect (now, AI12-0296-1), you could have called them "null". (Ducking incoming brickbats... :-) **************************************************************** @@ -6147,38 +6078,38 @@ From: Tucker Taft Sent: Monday, January 7, 2018 3:32 PM -> 13) Is the standard "No storage .. shall be lost" implementation -> requirement what we want here? For example, does this wording preclude -> a "unique number table" type of implementation and, if it does, is +> 13) Is the standard "No storage .. shall be lost" implementation +> requirement what we want here? For example, does this wording preclude +> a "unique number table" type of implementation and, if it does, is > this a problem? > status: undecided -> +> > 14) The thorniest set of problems has to do with Bounded_Big_Integers. -> Bob and Randy argue that Bounded_Big_Integers should not be a generic -> with a formal Capacity parameter and that instead it should be a -> non-generic package and the type -> Bounded_Big_Integers.Optional_Big_Integer should have a visible +> Bob and Randy argue that Bounded_Big_Integers should not be a generic +> with a formal Capacity parameter and that instead it should be a +> non-generic package and the type +> Bounded_Big_Integers.Optional_Big_Integer should have a visible > Capacity discriminant (with no default value). > There are other questions too, but let's start with that one. -> +> > There are drawbacks to the discriminated approach:... -I think we can leave the wording about "No storage shall be lost" as is. We -could add an AARM note clarifying that this is intended to permit caching or -unique-num tables. I don't see the need for an explicit "Implementation -Permission." Compiler customers will make their concerns known if they really +I think we can leave the wording about "No storage shall be lost" as is. We +could add an AARM note clarifying that this is intended to permit caching or +unique-num tables. I don't see the need for an explicit "Implementation +Permission." Compiler customers will make their concerns known if they really care. -I agree with keeping the bound as a generic formal. Bounded_String works this -way, so that is a precedent. And anything where each object has its own bound +I agree with keeping the bound as a generic formal. Bounded_String works this +way, so that is a precedent. And anything where each object has its own bound seems like a nightmare to maintain as the rest of the code changes. And as you -point out, if it is a discriminant that will inevitably mean heavier use of -more expensive function returns, which runs counter to the purpose of bounding +point out, if it is a discriminant that will inevitably mean heavier use of +more expensive function returns, which runs counter to the purpose of bounding the size. -I would also support carving bounded big nums off as a separate AI, and not -including it in this revision of the standard, but having it "out there" as -an AI for anyone to use as a model for a package they implement, should they +I would also support carving bounded big nums off as a separate AI, and not +including it in this revision of the standard, but having it "out there" as +an AI for anyone to use as a model for a package they implement, should they so choose. *************************************************************** @@ -6186,65 +6117,65 @@ From: Randy Brukardt Sent: Monday, January 7, 2018 4:01 PM -> I think we can leave the wording about "No storage shall be lost" as -> is. We could add an AARM note clarifying that this is intended to -> permit caching or unique-num tables. I don't see the need for an +> I think we can leave the wording about "No storage shall be lost" as +> is. We could add an AARM note clarifying that this is intended to +> permit caching or unique-num tables. I don't see the need for an > explicit "Implementation Permission." > Compiler customers will make their concerns known if they really care. -I agree. Storage being lost would be a significant problem for long running -programs, so it seems wrong for a general-purpose library. The RM should be +I agree. Storage being lost would be a significant problem for long running +programs, so it seems wrong for a general-purpose library. The RM should be clear that never recovering storage is incorrect. However, how often storage is recovered and similar topics, though, are between an implementer and their customers. -> I agree with keeping the bound as a generic formal. +> I agree with keeping the bound as a generic formal. > Bounded_String works this way, so that is a precedent. -Yup, it's bad enough that there is almost no use to bounded strings. :-) I've -stopped trying to use them at all because of that. Surely, let's double down +Yup, it's bad enough that there is almost no use to bounded strings. :-) I've +stopped trying to use them at all because of that. Surely, let's double down on a mistake. -> And anything where each object has its own bound seems like a -> nightmare to maintain as the rest of the code changes. And as you -> point out, if it is a discriminant that will inevitably mean heavier -> use of more expensive function returns, which runs counter to the +> And anything where each object has its own bound seems like a +> nightmare to maintain as the rest of the code changes. And as you +> point out, if it is a discriminant that will inevitably mean heavier +> use of more expensive function returns, which runs counter to the > purpose of bounding the size. -I don't understand this last point. A discriminant is just a constant -component, and build-in-place works the same way for records regardless of -the component types (assuming the type is not mutable). +I don't understand this last point. A discriminant is just a constant +component, and build-in-place works the same way for records regardless of +the component types (assuming the type is not mutable). -Moreover, for Janus/Ada, adding genericity makes things slower in general +Moreover, for Janus/Ada, adding genericity makes things slower in general (since it requires passing around descriptors), so it seems likely that the discriminant approach would be a bit more efficient (fewer things to pass into these functions). -Moral: I don't think we ought to make the decision here based on efficiency -concerns -- they vary wildly -- usability is much more important. Steve's +Moral: I don't think we ought to make the decision here based on efficiency +concerns -- they vary wildly -- usability is much more important. Steve's arguments about assignment are much more important than anything to do with -efficiency. (Aside: The bounded containers use a procedure Assign for +efficiency. (Aside: The bounded containers use a procedure Assign for assignment; that wasn't an option that Steve considered, I'm not sure why. Perhaps assignment is less likely for the containers than for BigNums.) - -> I would also support carving bounded big nums off as a separate AI, -> and not including it in this revision of the standard, but having it -> "out there" as an AI for anyone to use as a model for a package they + +> I would also support carving bounded big nums off as a separate AI, +> and not including it in this revision of the standard, but having it +> "out there" as an AI for anyone to use as a model for a package they > implement, should they so choose. -Yes, I fully concur with this. This doesn't seem sufficiently baked at the -moment, and I'm not sure there is enough baking time left. (We don't want to +Yes, I fully concur with this. This doesn't seem sufficiently baked at the +moment, and I'm not sure there is enough baking time left. (We don't want to be that chef that serves our clients raw bread pudding. ;-) -We need to figure out a reasonable implementation-independent way to specify +We need to figure out a reasonable implementation-independent way to specify the capacity that makes sense for the user view (and not from some theoretical implementation view). Perhaps that would answer the other questions anyway (if the capacity is specified as a real value, then it can't be a discriminant). -One possibility is to simply specify the bounds (like with other integer -types), probably as real values, and left the implementation figure out how +One possibility is to simply specify the bounds (like with other integer +types), probably as real values, and left the implementation figure out how convert that into bytes or nibbles or whatever representation it is using. -(It would be tempting to specify the bounds as unbounded bignums, but that +(It would be tempting to specify the bounds as unbounded bignums, but that of course eliminates the solution.) **************************************************************** @@ -6253,24 +6184,24 @@ Sent: Monday, January 7, 2018 5:00 PM >> ... -> ->> And anything where each object has its own bound seems like a ->> nightmare to maintain as the rest of the code changes. And as you ->> point out, if it is a discriminant that will inevitably mean heavier ->> use of more expensive function returns, which runs counter to the +> +>> And anything where each object has its own bound seems like a +>> nightmare to maintain as the rest of the code changes. And as you +>> point out, if it is a discriminant that will inevitably mean heavier +>> use of more expensive function returns, which runs counter to the >> purpose of bounding the size. -> -> I don't understand this last point. A discriminant is just a constant -> component, and build-in-place works the same way for records +> +> I don't understand this last point. A discriminant is just a constant +> component, and build-in-place works the same way for records > regardless of the component types (assuming the type is not mutable). -If the caller doesn't know the size of the object being returned, then you -inevitably end up doing some sort of secondary stack or heap allocation. -The point of having a bounded type is usually to reduce the amount of dynamic -allocation, so having object's whose size is unknown to the caller makes +If the caller doesn't know the size of the object being returned, then you +inevitably end up doing some sort of secondary stack or heap allocation. +The point of having a bounded type is usually to reduce the amount of dynamic +allocation, so having object's whose size is unknown to the caller makes function return more expensive, even if you are doing build in place. -In any case, if we agree to defer bounded big nums, then we don't have to +In any case, if we agree to defer bounded big nums, then we don't have to agree on the bounding mechanism. **************************************************************** @@ -6278,7 +6209,7 @@ From: Randy Brukardt Sent: Tuesday, January 8, 2018 7:56 PM -> The attached version #5 of this AI is intended to address +> The attached version #5 of this AI is intended to address > issues/questions raised since distribution of version #4 on 12/2/18. Typos that I fixed while posting: @@ -6287,28 +6218,28 @@ > The declaration of the generic library package Big_Numbers.Bounded_Big_Integers -> has the same contents and semantics as +> has the same contents and semantics as > Big_Numbers.Optional_Big_Integer except: Cool! There is a package Optional_Big_Integer! I wonder if it is optional? :-) -It looks like the original name was missing the "s" (Big_Integer{s}), and thus +It looks like the original name was missing the "s" (Big_Integer{s}), and thus the global replace went too far. -Also, when naming packages in the Standard, we usually drop "Ada" and leave +Also, when naming packages in the Standard, we usually drop "Ada" and leave everything else. (That was the silliest decision ever; I recall someone wanted the text of the Standard to be shorter, and that was the MRT response - drop 4 characters in a handful of places.) -So this needs to include the "Numerics" part in this wording. (See how A.5.2 +So this needs to include the "Numerics" part in this wording. (See how A.5.2 and A.5.3 present their packages.) And drop "Ada." wherever it appears in the text. (Gotta save those 4 characters! :-) > Each subprogram of an instance of > Bounded_Big_Integers.Bounded_Optional_Big_Integer -> behaves like the corresponding Big_Numbers.Big_Integers subprogram +> behaves like the corresponding Big_Numbers.Big_Integers subprogram > except that type invariant checks are performed as described in 7.3.2. ??? What is Bounded_Optional_Big_Integer? It isn't mentioned anywhere else. @@ -6316,39 +6247,39 @@ Big_Numbers.Bounded_Big_Integers? I've assumed that's the intent. > Big_Number_Check -> +> > Perform the checks associated with Pre, Static_Predicate, Dynamic_Predicate, -> or Type_Invariant aspect specifications occuring in the visible part +> or Type_Invariant aspect specifications occuring in the visible part > of package Ada.Big_Numbers or of any of its descendants. -No package "Ada.Big_Numbers", it's "Ada.Numerics.Big_Numbers" (and we always +No package "Ada.Big_Numbers", it's "Ada.Numerics.Big_Numbers" (and we always drop the "Ada." in text). ============ Technical issues on this (I didn't make any of these changes): -My intent was that there was one such suppression check per subsystem, so this +My intent was that there was one such suppression check per subsystem, so this would be: Numeric_Check - -Perform the checks associated with Pre, Static_Predicate, Dynamic_Predicate, -or Type_Invariant aspect specifications occuring in the visible part of + +Perform the checks associated with Pre, Static_Predicate, Dynamic_Predicate, +or Type_Invariant aspect specifications occuring in the visible part of package Numerics or of any of its descendants. -The idea is that there would also be "String_Check" (for Ada.Strings), -"Character_Check" (for Ada.Characters), "IO_Check" (for the packages that +The idea is that there would also be "String_Check" (for Ada.Strings), +"Character_Check" (for Ada.Characters), "IO_Check" (for the packages that should have been in Ada.IO, Text_IO, Sequential_IO, etc.), "System_Check" -(for System), and "Interface_Check" (for Interfaces). Of course, those only +(for System), and "Interface_Check" (for Interfaces). Of course, those only matter if we start defining preconditions and the like for them. ---- -Type_Invariants are required to be followed by 1.1.3(17.1/5); there's no -reason to suppress them as they can't fail for a correct implementation (same -reason we don't include postconditions here). I could see a compiler -generating them for debugging purposes, but that wouldn't be the standard +Type_Invariants are required to be followed by 1.1.3(17.1/5); there's no +reason to suppress them as they can't fail for a correct implementation (same +reason we don't include postconditions here). I could see a compiler +generating them for debugging purposes, but that wouldn't be the standard mode (what compiler wants to generate unnecessary code??). ---- @@ -6358,12 +6289,59 @@ ---- -We need to mention instances of generic units here as well. Adapting the +We need to mention instances of generic units here as well. Adapting the current wording of the Containers version with all of the above: -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 +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. + +**************************************************************** + +From: Steve Baird +Sent: Tuesday, January 29, 2018 7:23 PM + +The attached version #6 of this AI is intended to address issues/questions +raised since distribution of version #5 on 1/17/19. [This is version /08 of +the AI - Editor.] + +A summary of those issues/questions, along with their proposed resolutions, +follows below. The big one is splitting the Bounded_Big_Integers package off +into a separate AI. + +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). + +2) The second argument for the "**" operators for Big_Integer and + Big_Rational is of type Integer, not Big_Integer. + +3) There is one TBD remaining in the AI text having to do with a + choice of names for the Null/Nil/Undefined/Missing/Whatever + Big_Integer and Big_Rational values and for the corresponding + predicate. + + The AI as written uses the names + No_Big_[Integer,Rational] and Is_Present. + An earlier version I was discussing with Tuck had the names + Null_Big_[Integer,Rational] and Is_Present + and Tuck did not care for those. We discussed several alternatives, + which are also listed in the AI: + + 1) Is_Null and Null_Big_Integer + 2) Augment #1 with a Not_Null function + (i.e. provide both polarities, like "=" and "/="). + 3) Is_Valid and Invalid_Big_Integer. + 4) Is_Defined and Undefined_Big_Integer. + 5) Is_Present and Null_Big_Integer. + 6) Is_Present and No_Big_Integer. + + We may need a straw poll for this one. I'll note that + "No_Big_Xxx" is consistent with Ada.Tags.No_Tag. Opinions? + +4) Remove the Bounded_Big_Integers proposal from this AI so that it + becomes a separate AI (which, obviously, depends on this AI). + [This is now AI12-0305-1 - Editor.] ****************************************************************

Questions? Ask the ACAA Technical Agent