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

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

--- ai12s/ai12-0208-1.txt	2018/03/30 02:44:40	1.7
+++ ai12s/ai12-0208-1.txt	2018/06/05 22:33:45	1.8
@@ -3143,3 +3143,197 @@
 readers will be puzzled otherwise (including, most likely, us).
 
 ****************************************************************
+
+From: Steve Baird
+Sent: Tuesday, June 5, 2018  3:08 PM
+
+>> Attached is proposed wording for this AI.
+>>
+>> There are some TBDs interspersed.
+> 
+> Here's a few thoughts:
+> 
+>> [TBD: aspects specified for this package? Pure, Nonblocking, others?
+>> Same question applies to other packages declared in later sections.
+>> Would these aspects constrain implementations in undesirable ways?]
+> 
+> All of the packages should be nonblocking. I don't think any reasonable
+> implementation would need access to delay statements. ;-)
+> 
+
+Sounds good.
+
+> The interface package should be Pure (why not, it doesn't have any
+> implementation). The bounded package also should be pure (we do that for all
+> of the bounded forms elsewhere.
+> 
+> The others probably should be preelaborated (and the types having
+> preelaborable_initialization), lest we make it too hard to use the needed
+> dynamic allocation.
+> 
+
+Also sounds good.
+
+>> [TBD: It would be nice to use subtypes in parameter profiles (e.g.,
+>> a Nonzero_Number subtype for second argument of "/", but this requires
+>> AI12-0243 and the future of that AI is very uncertain.]
+> 
+> You can always use a Pre'Class as an alternative to a subtype. It's not
+> quite as convenient, but it makes the same check, and presuming that
+> AI12-0112-1 stays are currently envisioned, that check would be suppressible
+> with "pragma Suppress (Numerics_Check);".
+> 
+
+Let's leave things as I originally proposed for now, with a possible
+revision if AI12-0243 is approved.
+
+>> [TBD: Remove Integer_Literal aspect spec if AI12-0249-1 not approved.
+>> If Default_Initial_Condition AI12-0265-1 is approved and Integer_Literal AI
+> is
+>> not then replace "0" with "+0" in the condition and as needed in
+>> subsequent conditions.]
+> 
+> I put the AI number in here for Default_Initial_Condition.
+> 
+
+Thanks.
+
+>> [TBD: In_Range formal parameter names. "Lo & Hi" vs. "Low & High"?]
+> 
+> Ada usually doesn't use abbreviations, and saving one or two characters this
+> way isn't appealing. Use Low and High.
+> 
+
+You convinced me. Sounds good.
+
+>> A.5.5.1.1 Bounded Big Integers
+> 
+> Umm, please, no 5 level subclauses. Since there are currently no four level
+> items in the RM, we need to discuss that explicitly. I had to add a fourth
+> level for ASIS, but Ada only uses three levels. And the ACATS only uses two
+> levels in the annexes, which is already a problem for the containers (there
+> being only one set of sequence numbers for all of the containers tests).
+> 
+
+What would you suggest instead?
+
+>> AARM Note: Roughly speaking, behavior is as if the type invariant for
+>> Bounded_Big_Integer is
+>>   In_Range (Bounded_Big_Integer, First, Last) or else (raise
+> Constraint_Error)
+>> although that is not specified explicitly because that would
+>> require introducing some awkward code in order to avoid infinite
+>> recursion.
+> 
+> Awkward code? Please explain. Type invariants are explicitly not enforced on
+> 'in' parameters of functions specifically to avoid infinite recursion in the
+> type invariant expression. You'd probably need a function for this purpose
+> (to avoid the functions First and Last -- is that what you meant??), say:
+>       In_Base_Range (Bounded_Big_Integer) or else (raise Constraint_Error)
+> where In_Base_Range is equivalent to In_Range (Bounded_Big_Integer, First,
+> Last) with the expressions of First and Last substituted. One could also
+> make those expressions the defaults for Low and High.
+
+Ok, we can make this type invariant explicit.
+
+> 
+>> [TBD: This could be done differently by using a formal instance instead
+>> of declaring the Conversions package as a child of Bounded_Big_Integers.
+>> Would there be any advantage to this approach? The advantage of the
+>> proposed approach is visibility of the private part, but it does seem
+>> awkward to have a generic with no generic formals and no local state.]
+> 
+> Well, it would be easier to implement in Janus/Ada, where we never got
+> sprouting to work. But that's hardly a reason. I suspect it would be more
+> obvious what's going on than a generic child -- as a data point, all of the
+> extra operations of Ada.Strings.Bounded take formal packages rather than
+> being children -- but that may have been driven by other considerations.
+> 
+> One argument for making it a formal package is that this conversion package
+> really belongs to both big number packages -- it's somewhat artificial to
+> make it live in the hierarchy of one or the other.
+> 
+
+I don't see any real strong arguments one way or the other here
+(it would probably be ok to settle this one with a coin-flip)
+but I agree that it does seem odd to put it in one hierarchy or
+the other. So let's do it with a formal instance.
+
+>> Any Big_Rational result R returned by any of these functions satisfies the
+>> condition
+>>    (R = 0.0) or else
+>>    (Greatest_Common_Denominator (Numerator (R), Denominator (R)) = 1).
+> 
+> Arguably, that should be a postcondition, since the implementation isn't
+> required to check it (it it required to *pass* it). Then a separate rule
+> isn't needed. You'd probably want to declare a function with this meaning,
+> 'cause duplicating the above 2 dozen times would be annoying.
+> 
+
+Ok, let's make the postconditions explicit.
+
+>> AARM Note: No Bounded_Big_Rationals generic package is provided.
+> 
+> We've discussed why, but there needs to be a version of that discussion
+> either in this note or in the (sadly empty) !discussion section. Future
+> readers will be puzzled otherwise (including, most likely, us).
+
+Agreed, more should be said about this in the !discussion section.
+
+Thanks, as always, for the feedback.
+
+Do we want revised wording incorporating what we have
+discussed here for Lisbon?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, June 5, 2018  3:28 PM
+
+...
+> >> A.5.5.1.1 Bounded Big Integers
+> > 
+> > Umm, please, no 5 level subclauses. Since there are currently no 
+> > four level items in the RM, we need to discuss that explicitly. I 
+> > had to add a fourth level for ASIS, but Ada only uses three levels. 
+> > And the ACATS only uses two levels in the annexes, which is already 
+> > a problem for the containers (there being only one set of sequence 
+> > numbers for all of the containers tests).
+> 
+> What would you suggest instead?
+
+There aren't any great answers here.
+
+If you want to keep these in with the other numerics packages, then I think
+you need a flat organization: A.5.5 Big Integer Interface, A.5.6 Unbounded 
+Big Integers A.5.7 Bounded Big Integers etc. That's how the queues are 
+organized, after all, they have the same issue.
+
+Alternatively, given that this is a substantial subsystem unto itself, you
+could just give them there own subclause in Annex A:
+
+A.20 Big Numbers A.20.1 Big Integer Interface, A.20.2 Unbounded Big Integers
+A.20.3 Bounded Big Integers etc.
+
+...
+> Do we want revised wording incorporating what we have discussed here 
+> for Lisbon?
+
+Always best to have the latest into the actual AI. Otherwise, we end up saying
+stuff like "ignore that part of the AI, we decided to change it in e-mail" and
+people get all confused. And end up asking questions about "that part of the
+AI" anyway.
+
+****************************************************************
+
+From: Jeff Cousins
+Sent: Tuesday, June 5, 2018  4:23 PM
+
+> Do we want revised wording incorporating what we have discussed here
+> for Lisbon?
+
+
+Yes please, the more that can be tidied up beforehand the better.
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent