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

Differences between 1.3 and version 1.4
Log of other versions for file ai12s/ai12-0442-1.txt

--- ai12s/ai12-0442-1.txt	2022/06/14 23:39:33	1.3
+++ ai12s/ai12-0442-1.txt	2022/06/21 03:14:39	1.4
@@ -1,4 +1,4 @@
-!standard 3.4(34)                                       22-05-25  AI12-0442-1/03
+!standard 3.4(34)                                       22-05-25  AI12-0442-1/03
 !standard 3.5(58)
 !standard 3.5.5(12)
 !standard 3.5.9(22)
@@ -7,6 +7,7 @@
 !standard 3.9(27)
 !standard 3.9.3(16)
 !standard 3.9.4(26/2)
+!standard 3.9.4(33/2)
 !standard 3.10.2(39)
 !standard 4.3.5(85/5)
 !standard 4.7(9)
@@ -201,8 +202,8 @@
    An interface such as Queue can be used directly as the parent of a new type
    (as shown here), or can be used as a progenitor when a type is derived. In
    either case, the primitive operations of the interface are inherited. For
-   Queue, the implementation of the four inherited routines {will be required
-   to}[must] be provided. Inside the call of Transfer, calls will dispatch to
+   Queue, the implementation of the four inherited routines {will
+   necessarily}[must] be provided. Inside the call of Transfer, calls will dispatch to
    the implementations of Append and Remove_First for type Fast_Food_Queue.
 
 Modify 3.10.2(39):
@@ -1705,5 +1706,561 @@
 possible for the implementation to notice the default value being assigned 
 and continue to avoid materializing the attribute. It's already a 
 "possibility" statement because of the "can", we don't have to repeat that.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, June 9, 2022  1:39 AM
+
+(Note: I'm sending this here as it *might* end up being addressed in the FDIS; 
+if not, it will get moved to the new system.)
+
+In applying wording changes, I happened to notice that the Random Number Note
+3 (A.5.2(50-54)) gives bad advice. In particular, AI12-0144-1 added a discrete
+random function Random with an explicit range as simple transformations, such
+as the one given in this note, do not actually give a uniform distribution.
+(The integer conversion is not necessarily uniform, even if the real input to
+it is.)
+
+Since we added this new routine specifically to handle the supposedly special
+cases, the note should simply say that applications should use the Random
+functionS (the S being new to the note) in an instance of Discrete.Random.
+
+We don't necessarily need to fix this note in the FDIS (since it was been 
+giving out bad advice since 1995, what's another 5 years? :-) OTOH, we know
+the advice is bad (especially when the formula doesn't use an explicit
+Truncate!), and we don't need it anymore, so we could just delete it (which
+would seem to be in bounds for the FDIS).
+
+If we were starting anew, perhaps we would explain why "obvious"
+transformations are unlikely to be uniformly distributed, but that would be
+too much for the FDIS, and might be too complex for the RM anyway. We could
+just add a short AARM note instead (which we can always do).
+
+It's not clear to me whether the advice about an exponential distribution is
+actually correct, but it at least avoids the problems inherent from a type
+conversion.
+
+So this would end up looking something like (I'm not showing the extensive
+deletion here):
+
+---
+
+NOTE 3 A given implementation of the Random function in Numerics.Float_Random
+is not guaranteed to be capable of delivering the values 0.0 or 1.0.
+Applications will be more portable if they assume that these values, or values
+sufficiently close to them to behave indistinguishably from them, can occur.
+If a sequence of random integers from some fixed range is necessary, the
+application should use {one of} the Random function{s} in an appropriate
+instantiation of Numerics.Discrete_Random, rather than transforming the 
+result of the Random function in Numerics.Float_Random.
+
+AARM Discussion: One might think that a simple transform like
+         Integer(Float(M) * Random(G)) mod M
+would give an uniform distribution from 0 .. M-1. But that only works if 
+underlying random generator has a period of a multiple of M; otherwise, the
+integer conversion would convert differing numbers of the original random
+values into each result value, making the distribution not quite uniform.
+Doing this correctly requires care, and thus a user should use the provided
+functions (which hopefully have been implemented correctly, see AI12-0144-1
+for a possible correct implementation) rather than "rolling their own"
+solution.
+End AARM Discussion.
+
+Exponentially distributed (floating point) random numbers with mean and 
+standard deviation 1.0 can be obtained by the transformation 
+
+    -Log(Random(G) + Float'Model_Small)
+
+where Log comes from Numerics.Elementary_Functions (see A.5.1); in this 
+expression, the addition of Float'Model_Small avoids the exception that would
+be raised were Log to be given the value zero, without affecting the result
+(in most implementations) when Random returns a nonzero value. 
+
+[In the above, parts of paragraphs 50 and 52 are deleted, along with all of
+51. Argubly, the second part should now start a new note (that is, NOTE 4)
+rather than be part of the first note, since it doesn't seem related to the
+remaining part.]
+
+------------
+
+Should this be done now as part of the presentation changes for the FDIS, or
+should we do a complete AI on the topic?? Should these be treated as two
+separate notes??
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, June 9, 2022  7:26 AM
+
+I would suggest postponing this and doing a "real" AI.  I see no urgency 
+whatsoever, particularly since no one looks at the FDIS.  For advice, my guess
+is folks use the online RM, which presumably will incorporate this sort of
+update relatively soon, even if it isn't in the "official" Ada 2022 RM.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, June 9, 2022  7:40 AM
+
+> In applying wording changes, I happened to notice that the Random 
+> Number Note 3 (A.5.2(50-54)) gives bad advice. In particular, 
+> AI12-0144-1 added a discrete random function Random with an explicit 
+> range as simple transformations, such as the one given in this note, 
+> do not actually give a uniform distribution. (The integer conversion 
+> is not necessarily uniform, even if the real input to it is.)
+
+Is the Advice really so bad?  It says, "...provided that M is not too large".
+Doesn't that assumption imply that it's pretty close to uniform?
+
+But Randy's suggested change is desirable anyway.  Now that we have a Random
+function that takes a range, there's no need to be horsing around with
+floating point.
+
+P.S. I agree with Tucker that there's no hurry.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, June 9, 2022  1:51 PM
+
+When I said "FDIS", I also meant the final published Ada 2022 RM. That's the 
+version most people will be using for the next 5 years (at least until a 
+Corrigendum is published, but experience suggests that many will still use 
+the original version even after that). Sorry about any confusion on that 
+point.
+
+Few people use the online draft version, especially early in a cycle (nor 
+should they), so the existence of that is pretty much irrelevant.
+
+Does this change your answer? (I'm saying that to both Tuck and Bob)
+
+As far as being Uniformly distributed, for many applications, close enough 
+will cost money or allow security breaches. It's just plain bad to give such
+advice without explaining that it is not exactly true. And a distribution is
+not uniformly distributed if it is "close"; if the text said "close to a
+uniform distribution" that would be better. But as Bob noted, there is no
+reason to mention this at all anymore.
+
+I do think we should fix it, but I agree that it is marginal -- if someone
+with a high-security application is getting their numerics advice from the
+RM, they do not really understand their job.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, June 9, 2022  5:11 PM
+
+> When I said "FDIS", I also meant the final published Ada 2022 RM. That's the
+> version most people will be using for the next 5 years (at least until a 
+> Corrigendum is published, but experience suggests that many will still use
+> the original version even after that). Sorry about any confusion on that 
+> point.
+>
+> Few people use the online draft version, especially early in a cycle (nor 
+> should they), so the existence of that is pretty much irrelevant.
+
+Not sure I agree, but in any case, I don't think the advice in a section about
+Random numbers deserves our attention at this point.  We have bigger fish to
+fry...
+
+> Does this change your answer? (I'm saying that to both Tuck and Bob)
+
+Not really.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, June 9, 2022  5:14 PM
+
+But let me add, if you (Randy, aka the Editor) are so inspired, then go for
+it.  I don't think anyone will object either way.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, June 10, 2022  12:47 AM
+
+>>Few people use the online draft version, especially early in a cycle 
+>>(nor should they), so the existence of that is pretty much irrelevant.
+
+>Not sure I agree, ...
+
+I'm not sure what you are not agreeing with, but I was simply referring to 
+the numbers from our "usage of the Ada Standard" web report. Draft Ada 2022
+usage is slowly growing, but still is below 10% of all usage of Ada Standards.
+It's about the same as usage to Ada 2012+TC1, and about a third of the usage 
+of Ada 2012.
+
+Moreover, in the early days of that draft (which goes back to 2013), the usage
+was 4-6%. The usage didn't really grow until 2020.
+
+When that draft originally comes out, it is mainly aimed at implementers and
+ACATS testers (who need to know the bleeding edge of Ada rules). For everyone
+else, it is changing too much to be something to rely on. Once we get near the
+end of a development cycle (like now), that will differ, of course.
+
+The vast majority of use of Ada standards is to the major published versions 
+(Ada 2005 and Ada 2012 primarily). People of course also use off-line versions,
+but obviously those don't get updated either.
+
+Getting back to the point, it seems likely that most users won't see the next 
+standard until whenever we do the next revision.
+
+Anyway, this is way too much detail (and mostly off topic!), but I just wanted 
+to clarify what I was saying. It was carefully considered, not an off-the-cuff 
+remark.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, June 10, 2022  12:52 AM
+
+>But let me add, if you (Randy, aka the Editor) are so inspired, then go 
+>for it. I don't think anyone will object either way. 
+
+That WAS the question, after all.
+
+It's easier for me to do it now (no AI to write, no agenda item or meeting 
+time spent, no minutes to write after a meeting, etc.). I can just stick it
+in AI12-0442-1 (I think that's the right one) and do it immediately.
+
+It sure seems more valuable to me (and to Ada users) than rewriting the 75th 
+occurrence of "need not". :-) And I think as a pure deletion of part of a note
+(and one that needed rewriting anyway), I think it is in bounds.
+
+Does anyone actually object to doing this now???
+
+****************************************************************
+
+From: Tullio Vardanega
+Sent: Friday, June 10, 2022  1:52 AM
+
+In fact, I agree to Randy's stance here.
+
+****************************************************************
+
+From: Jeff Cousins
+Sent: Friday, June 10, 2022  2:32 AM
+
+Ok with me if you go for it.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, June 11, 2022  2:01 AM
+
+Following are some fixes to the approved changed wording of the various FDIS 
+AI. There also were a few typos in the AIs (stray brackets, missing words in
+Editor's notes) that I won't bother to explain.
+
+I'm not quite done applying the new wording, so there might be another item
+or two on Monday, but I'm sending this now so that you can review it and
+highlight any issues before I button this up.
+
+[Editor's note: only issues relevant to this AI are shown here; others
+are recorded in other relevant AIs.]
+
+----
+
+In AI12-0442-1, we have:
+
+  Modify 3.5(58):
+
+    NOTE 2   For a subtype of a scalar type, the result delivered by the
+    attributes Succ, Pred, and Value {can be outside}[might not belong to]
+    the subtype; similarly, the actual parameters of the attributes Succ,
+    Pred, and Image {are also allowed to be outside}[need not belong to]
+    the subtype.
+
+This AI is about notes, where "may" is not allowed. However, "is allowed" is
+defined to be a synonym of "may", so "are also allowed" isn't allowed (pun
+intended) either. I replaced this by:
+
+  Modify 3.5(58):
+
+    NOTE 2   For a subtype of a scalar type, the result delivered by the
+    attributes Succ, Pred, and Value {can be outside}[might not belong to]
+    the subtype; similarly, the actual parameters of the attributes Succ,
+    Pred, and Image {can also be outside}[need not belong to] the subtype.
+
+which is shorter anyway.
+
+The same issue, with the same fix, also occurs in 3.5.5(12).
+
+-----
+
+The Note 6.1.2(44/5) says:
+
+NOTE For an example of the use of these aspects and attributes, see the Vector 
+container definition in A.18.2.
+
+But 6.1.2 doesn't contain any attributes anymore, so this should just say:
+
+NOTE For an example of the use of these aspects, see the Vector container 
+definition in A.18.2.
+
+I added this to AI12-0442-1.
+
+In so doing, I noticed that 6.1.2(18/5) was in that AI, but that is not a 
+note or example -- it is in the wrong AI. So I moved that paragraph to 
+AI12-0445-1.
+
+---------------
+
+In AI12-0442-1, D.3(21) reads:
+
+    NOTE 4   When specifying the ceiling of a protected object, [one should
+    choose] a {correct }value that is {one that is }at least as high
+    as the highest active priority
+    at which tasks can be executing when they call protected operations of
+    that object. In determining this value the following factors, which
+    can affect active priority, {are relevant}[should be considered]:
+    the effect of Set_Priority, nested protected operations, entry calls,
+    task activation, and other implementation-defined factors.
+
+There is an extra "that" remaining here, this should be:
+
+    NOTE 4   When specifying the ceiling of a protected object, [one should
+    choose] a {correct }value {is one }that is at least as high
+    as the highest active priority
+    at which tasks can be executing when they call protected operations of
+    that object. In determining this value the following factors, which
+    can affect active priority, {are relevant}[should be considered]:
+    the effect of Set_Priority, nested protected operations, entry calls,
+    task activation, and other implementation-defined factors.
+
+-------------------
+
+In AI12-0442-1, 12.6(11) is modified to remove "need not" as follows:
+
+    NOTE 1   The matching rules for formal subprograms state requirements
+    that are similar to those applying to subprogram_renaming_declarations
+    (see 8.5.4). In particular, the name of a parameter of the formal 
+    subprogram {can be different from}[need not be the same as] that of the
+    corresponding parameter of the actual subprogram; similarly, for these 
+    parameters, default_expressions need not correspond.
+
+But there is a second occurrence of "need not" that also needs to be replaced.
+
+    NOTE 1   The matching rules for formal subprograms state requirements
+    that are similar to those applying to subprogram_renaming_declarations
+    (see 8.5.4). In particular, the name of a parameter of the formal 
+    subprogram {can be different from}[need not be the same as] that of the
+    corresponding parameter of the actual subprogram; similarly, for these 
+    parameters, default_expressions {can be different}[need not correspond].
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Saturday, June 11, 2022  8:14 AM
+
+All look good to me.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, June 14, 2022  8:36 PM
+
+Having finally finished applying all of the wording changes, I was able to
+check the result for words we're not supposed to be using. And surprise,
+there still were a dozen or so uses of words we were trying to eliminate.
+Some of those were errors applying changes (often cases where there were
+two changes in a paragraph, but only one change was applied). The rest are
+detailed below.
+
+Please read and comment (if needed) on these ASAP as I will be finishing 
+this project in the next few days (I hope!!).
+
+[Editor's note: only issues relevant to this AI are shown here; others
+are recorded in other relevant AIs.]
+
+In AI12-0442-1, 3.9.3(16) says:
+
+    NOTE 3   Notes on the example: Given the above abstract type, one
+    {can}[could then] derive various (nonabstract) extensions of the type,
+    representing alternative implementations of a set. One {possibility 
+    is to}[might] use a bit vector, but impose an upper bound on the largest
+    element representable, while another possible implementation 
+    is a hash table, trading off space for flexibility.
+
+But this is not the original wording for the last part of this paragraph; it
+originally said "might use". So the correct change is:
+
+    NOTE 3   Notes on the example: Given the above abstract type, one
+    {can}[could then] derive various (nonabstract) extensions of the type,
+    representing alternative implementations of a set. One {possibility 
+    is to}[might] use a bit vector, but impose an upper bound on the largest
+    element representable, while another {possible implementation 
+    is}[might use] a hash table, trading off space for flexibility.
+
+----------------
+
+3.9.4(33/2) abuses "must", and needs to be reworded.
+
+   An interface such as Queue can be used directly as the parent of a new type
+   (as shown here), or can be used as a progenitor when a type is derived.
+In
+   either case, the primitive operations of the interface are inherited. For
+   Queue, the implementation of the four inherited routines {will be required
+   to}[must] be provided. Inside the call of Transfer, calls will dispatch to
+   the implementations of Append and Remove_First for type Fast_Food_Queue.
+
+This was added to AI12-0442-1.
+
+----------------
+
+A number of Annex M (summary of Implementation-Defined and Implementation
+Advice) items contain banned words (as the original text did). I've fixed
+these  similarly to the base text (and did not otherwise document them, as
+is usual as they are considered non-normative).
+
+----------------
+
+The introduction to each subclause of Annex M contains a "must". I replaced 
+this with "is required to". This is not ideal, but as we are talking about 
+requirements given elsewhere, it's hard to find any language that doesn't 
+seem like itself a requirement.
+
+I put these 4 (!) changes into AI12-0442-1 (as this is not supposed to be 
+normative text, it follows from requirements elsewhere). (Note: If ISO
+complains about this Annex, I suggest we drop it altogether from the ISO
+version.)
+
+----------------
+
+9.9(8) has almost the same wording as 9.9(7), and it needs the same fixes,
+giving:
+
+    NOTE 3   Within protected units, {by}[algorithms] interrogating the
+    attribute E'Count in the entry_barrier for the entry E {an algorithm
+    can}[should take precautions to] allow for the evaluation of the
+    condition of the barrier both before and after queuing a given caller. 
+
+This was added to AI12-0442-1.
+
+----------------
+
+Arrrggghhh! The rewrite of A.5.2(50), the infamous Random number paragraph,
+did not get rid of "should". While I still think we need a "Usage Advice"
+category (so we can use "should" in cases like this), the best I can do is
+to express it as a "preference" (since a note cannot give a recommendation,
+period).
+
+Here's my fix:
+
+    NOTE 3   A given implementation of the Random function in
+    Numerics.Float_Random {is not guaranteed to}[may or may not]
+    be capable of delivering the values 0.0 or 1.0. {Applications will be
+    more portable if they}[Portable applications should] assume
+    that these values, or values sufficiently close to them to behave
+    indistinguishably from them, can occur. If a sequence of random
+    integers from some [fixed ]range is {necessary}[needed], {it is
+    preferred that }the application [should use]{uses one of} the
+    Random function{s} in an appropriate
+    instantiation of Numerics.Discrete_Random, rather than transforming
+    the result of the Random function in Numerics.Float_Random.[ However,
+    some applications
+    with unusual requirements, such as for a sequence of random integers
+    each drawn from a different range, will find it more convenient to
+    transform the result of the floating point Random function. For M >=
+    1, the expression]
+
+****************************************************************
+
+From: Jeff Cousins
+Sent: Wednesday, June 15, 2022  2:35 AM
+
+Thanks Randy, looks good.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, June 15, 2022  5:05 PM
+
+Most seem fine.  I have one comment on some awkward wording below.
+
+>3.9.4(33/2) abuses "must", and needs to be reworded.
+>
+>   An interface such as Queue can be used directly as the parent of a new type
+>   (as shown here), or can be used as a progenitor when a type is derived. In
+>   either case, the primitive operations of the interface are inherited. For
+>   Queue, the implementation of the four inherited routines {will be required
+>   to}[must] be provided. Inside the call of Transfer, calls will dispatch to
+>   the implementations of Append and Remove_First for type Fast_Food_Queue.
+
+This seems a bit awkward.  Perhaps more simply:
+
+
+For Queue, the four inherited routines have to be overridden.  Inside the call
+of Transfer ...
+
+
+ Not sure whether this uses any disallowed words...
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, June 15, 2022  7:27 PM
+
+"Has to" is a synonym of "shall", I presume the plural form "have to" is also 
+treated the same. "Shall" is not allowed here as this is associated with an
+example. As a practical matter, it is nearly impossible to talk about
+consequences of requirements in notes, because that necessarily uses the same
+wording as a requirement. 
+ 
+I have thought about registering a formal complaint with JTC1 (would have to go
+through SC 22, of course) about this problem, since it seems to be very
+important to be able to have notes about consequences and such consequences
+shouldn't be confused with actual requirements. ("can" works for possible
+consequences, of course, but when a consequence is inevitable, no wording
+exists that is both allowed and doesn't already reflect a requirement).
+ 
+In the above, I tried to use "will be required" to attempt to make it clear
+that this is not a requirement itself, but it is very close to the phrasing of
+a requirement and I'm dubious that it really would work if checked. I don't
+think it is likely that anyone will check all of the wording in detail; most
+likely, a check for unallowed words (like "might") will be done and that's
+about it. Checking notes is especially hard, there are too many to do by hand,
+so one would require a specialized tool to check them all -- I have such a
+tool but I doubt that ISO does.
+ 
+The only real solution to problems like this is to avoid the notes and
+examples that cause them. Probably would need to drop all notes that talk
+about consequences from the ISO version. But I don't expect it to come to
+that (at least not for that reason).
+ 
+If you can come up with some wording that doesn't use any phrases like the
+following:
+   is to
+   is required to
+   it is required that
+   has to
+   only … is permitted
+   it is necessary
+then please suggest it.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Sunday, June 19, 2022  3:28 PM
+
+>>This seems a bit awkward.  Perhaps more simply:
+>>
+>>For Queue, the four inherited routines have to be overridden.  Inside the
+>> call of Transfer ...
+
+Perhaps:
+
+  For Queue, the four inherited routines will necessarily be overridden.
+  Inside the call ...
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, June 20, 2022  9:12 PM
+
+That's probably better. While "necessary" is one of the words to avoid here,
+"necessarily" is not the same thing.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent