!standard 3.5.9(6) 15-03-25 AI05-0159-1/02 !standard 7.3.2(10/4) !standard 7.3.2(21/4) !standard 7.3.2(22.1/4) !standard 11.3(4.1/4) !standard A(3.1/4) !standard A.18.10(2/4) !class binding interpretation 15-03-23 !status work item 15-03-23 !status received 15-02-26 !priority Low !difficulty Easy !qualifier Omission !subject Corrections from the Corrigendum Editorial Review !summary Various issues with normative wording found during editorial reviews are addressed. !question (1) There does not appear to be any resolution rule that applies to a digits_constraint. Should there be one? (Yes.) (2) In 7.3.2(10/4) and 7.3.2(22.1/4), are the commas in the right place? (No.) (3) There is a missing "the" in 7.3.2(21/4). Should it be added? (Yes.) (4) In A.18.10(2/4), "consists of" would be better than "comprises of". The comma after root node seems misplaced. Should these be changed? (Yes.) (5) In A(3.1/4), we have both "input-output" and "input/output". One of them must be wrong, right? (Yes.) (6) In 11.3(4.1/4), "rather than" sounds odd. Wouldn't "instead of" be better? !recommendation (See Summary.) !wording [Note: Remove the name of the reviewer once this is finished and approved. It's here to speed discussion during the phone meeting.] (1) Add after 3.5.9(6): [Brukardt] The simple_expression of a digits_constraint is expected to be of any integer type. (2) Modify 7.3.2(10/4): [Moore] After successful explicit initialization of the completion of a deferred constant with a part of type T, if the completion is inside the immediate scope of the full view of T[,] and the deferred constant is visible outside the immediate scope of T, the check is performed on the part(s) of type T; Modify 7.3.2(22.1/4): [Dismukes] For an invariant check on a value of type T1 based on a class-wide invariant expression inherited from an ancestor type T, any operations within the invariant expression that were resolved as primitive operations of the (notional) formal derived type NT[,] are{,} in the evaluation of the invariant expression for the check on T1{,} bound to the corresponding operations of type T1. [Editor's note: 6.1.1(38/4) has similar text; if we move the commas in this paragraph, we need to do it in that one as well.] (3) Modify 7.3.2(21/4): [Moore] If performing checks is required by the Type_Invariant or Type_Invariant'Class assertion policies (see 11.4.2) in effect at the point of {the} corresponding aspect specification applicable to a given type, then the respective invariant expression is considered enabled. [Editor's note: Sadly, this word is missing from the unchanged part of the paragraph. It was a last-minute change in Ada 2012 that presumably didn't get reviewed enough. Thus this trivial change appears here.] (4) Modify A.18.10(2/4): [Barnes] A multiway tree container object manages a tree of nodes, {consisting}[comprising] of a root node {(see below)}, and {also} a set of internal nodes each of which contains an element and pointers to the parent, first child, last child, next (successor) sibling, and previous (predecessor) sibling internal nodes. A cursor designates a particular node within a tree (and by extension the element contained in that node, if any). A cursor keeps designating the same node (and element) as long as the node is part of the container, even if the node is moved within the container. (5) Modify A(3.1/4): [Barnes, Dismukes] For the purpose of determining whether concurrent calls on text input-output subprograms are required to perform as specified above, when calling a subprogram within Text_IO or its children that implicitly operates on one of the default input{-}[/]output files, the subprogram is considered to have a parameter of Current_Input or Current_Output (as appropriate). (6) Modify 11.3(4.1/4): [Taft, Barnes] If the evaluation of a string_expression or string_simple_expression raises an exception, that exception is propagated {instead of}[rather than] the one denoted by the exception_name of the raise_statement or raise_expression. !discussion (1) This appears to be an oversight. (2) Comma madness. :-) (3) Helps to edit. ;-) (4) "comprising of" is just weird. The comma after "root node" is also weird, but it is very important to the meaning (as the contents of the "root node" are defined in the next paragraph, it's not the list following "internal node"). Thus we adjust the wording to clarify that, and leave the comma in place. (5) The standard usually uses "input-output" to describe files, libraries, etc., not "input/output". (6) The RM/AARM uses "rather than" more often than "instead of". (175 occurrences to 55) Still, "instead of" sounds better to the Editor's ear as well as the commenter. !corrigendum 3.5.9(6) @dinsa For a type defined by a @fa, the @i of the type is specified by the value of the @fa given after the reserved word @b; this @fa is expected to be of any real type. For a type defined by a @fa (a @i fixed point type), the number of significant decimal digits for its first subtype (the @i of the first subtype) is specified by the @fa given after the reserved word @b; this @fa is expected to be of any integer type. @dinst The @fa of a @fa is expected to be of any integer type. !ASIS No ASIS effect. !ACATS test !appendix From: Randy Brukardt Sent: Thursday, February 26, 2015 11:15 PM I was wondering why I didn't need to fix up a resolution rule for digits_constraint. That turns out to be easy: there isn't any rule to fix up! 3.5.9 has resolution rules for Decimal_Fixed_Point_Definition and Ordinary_Fixed_Point_Definition, and requires staticness of all of these (including digits_constraint). But no resolution rule for the expression of the digits_constraint. This must be highly important, because its been true since the initial version of Ada 95. :-) One can sort of infer a resolution rule from 3.5.9(6) and from 3.5.7(4) [depending upon whether it is a float or decimal constraint], and of course there's Ada 83 (which treats types and subtypes the same). But it sure seems odd that we have a complete definition of delta_constraint in J.3, including resolution, and definitions of the resolution of all of the kinds of type definitions, yet we never mention resolution of digits_constraint in 3.5.9 or anywhere else. Adding "The simple_expression of a digits_constraint is expected to be of any integer type." to 3.5.9(6) would seem to be indicated. **************************************************************** From: Bob Duff Sent: Friday, February 27, 2015 9:46 AM > This must be highly important, because its been true since the initial > version of Ada 95. :-) Yeah, well for me this one falls into the category "waste of time". We all have better things to do than polishing the RM for years on end. **************************************************************** From: Randy Brukardt Sent: Friday, February 27, 2015 3:52 PM We could put it into the AI of "things we don't intend to fix". The AI of "things we don't intend to fix" contains cases where wording seems messy, and thus there is a significant chance of introducing bugs. I don't see how that applies here: "The simple_expression of a digits_constraint is expected to be of any integer type." is completely straighforward. I agree we shouldn't go looking for such things, but it's hard to justify ignoring them when found, especially when the amount of work is essentially the same either way. (I'd have to write up the issue and explain why we don't want to fix it; it'd be a lot easier to just do so.) In most such cases, we're talking about something muddled, as opposed to outright missing, which is not as clear-cut; it's likely to be more dangerous to change. The only question in my mind is whether 3.5.7(4) could be read to make the needed definition. The sentence doesn't mention what syntax it applies to, so one could argue that it is intended to apply to any expression that immediately follows "digits" in the syntax. But I don't buy that; the syntax in question isn't in this clause (which implies a long-distance effect that we typically avoid), and the value after digits is never referred to as "requested decimal precision" in 3.5.9 (where the syntax actually is), 3.5.9 specifically defines the resolution of the value after digits for a decimal_fixed_point_definition (which seems to put the lie to the idea that this was intended to apply to all expressions that follow "digits"), and indeed, the constraint doesn't even have to be used on a floating point value (so it seems odd to be using float-specific terminology with it). I've now probably spent 4 times as much time on this as it would have taken to just write up a trivial AI to insert the line. Demonstrates that not only are some things too simple that they're a waste of time to fix, but that's it's possible for them to be so simple that it's a waste of time to complain about them being a waste of time. :-) **************************************************************** From: Robert Dewar Sent: Friday, February 27, 2015 4:00 PM > I agree we shouldn't go looking for such things, but it's hard to > justify ignoring them when found, especially when the amount of work > is essentially the same either way. We could have the good taste just to ignore trivial matters without wasting time on them :-) **************************************************************** From: Bob Duff Sent: Friday, February 27, 2015 4:20 PM > I've now probably spent 4 times as much time on this as it would have > taken to just write up a trivial AI to insert the line. Demonstrates > that not only are some things too simple that they're a waste of time > to fix, but that's it's possible for them to be so simple that it's a > waste of time to complain about them being a waste of time. :-) I suggest you don't bring such issues up in the first place. Then nobody will waste time. Save it for cases where some compiler writer is genuinely confused, or where compilers disagree, and other useful cases. **************************************************************** From: Randy Brukardt Sent: Friday, February 27, 2015 5:53 PM So you want me to ignore anything I find in RM when working on the ACATS or when editing, because there's a 0% chance of me knowing anything about the above in those cases? (I'm neither acting as a compiler writer nor running multiple compilers in those roles [discounting Janus/Ada for this purpose, since it's rare that it provides useful information on the margins].) I can only find problems where the intent as I understand it doesn't match the actual wording, or as in this case, where there appears to be no wording at all. Trying to guess whether a bug is going to be "significant" to someone is not really practical. In general, people report far too few "trivial" things, meaning that they never get fixed. That's not even solely a software problem, you see that in retail and government and lots of other things as well. No one can fix things that they don't know about! Thus, I think pretty much everything should be *reported*, and leave it to our "triage" system to decide what is important enough to put on the ARG agenda. In this particular case, the bug is relatively horrible, in that the *type* of an entire Ada construct is never defined. That's of course mitigated by the fact that one can infer that it's supposed to work like other similar features, and of course by the fact that the specific feature is hardly ever used. It's these latter facts that give it a low priority, not the nature of the bug. Given that in this case the bug can be fixed by adding a single sentence, the sentence is similar to existing sentences, the sentence is specific to the feature in question so it can't cause any conflicts, and because fixing these things isn't done in a vacuum, but rather bundled with lots of other fixes (i.e. a Corrigendum) so the incremental cost is low, I sent it as a stand-alone report with the intent of writing a quickie AI to apply the fix. If the fix would have been more complex, I still would have sent a report, but would have suggested putting it into the "things we don't intend to fix" AI or just filing it into an AC. But never reporting problems means that future maintainers don't have the opportunity to fix things that we didn't, because no one can fix anything they don't know about. (That would be especially important should the standard get a complete overhaul, something I hope never happens. But I don't want to make it harder for future maintainers, either.) I don't want to be the sole arbiter of whether something needs fixing, and I surely don't want any other single individual making that call, either. And griping about what happens to be discovered really doesn't help, either. If you would like to propose some alternative process for dealing with reports like this one that does not involve sweeping them under the rug, please go ahead. It would be useful to have some lightweight way to deal with stuff of this sort (that's more than presentation, but obvious as to the fix). But I'm not at all on board with ignoring genuine bugs in the Standard (or anything, for that matter); there's a vast difference between "low priority" and "no priority". P.S. Now I'm up to 7 times as much time because I have to defend fixing actual bugs in the Standard. Grumble. **************************************************************** From: Robert Dewar Sent: Saturday, February 28, 2015 6:22 AM And you are wasting time because this defense is misguided IMO **************************************************************** From: Robert Dewar Sent: Saturday, February 28, 2015 6:24 AM Here's the deal Randy, the RM is full of errors about things that don't matter. Fixing one of them has no practical impact whatsoever. If you notice some small error where the intent is obvious and there is no real problem, you should ignore it. It would be nice to have a goal of a 100% error free RM, but that's unobtainable, so any action that has as part of its rationale achieving this is flawed, at least with respect to this rationale. **************************************************************** From: Robert Dewar Sent: Saturday, February 28, 2015 6:26 AM One way of handling absolutely trivial matters such as this where the fix is (a) unimportant to anyone and (b) trivial, is to just do the fix, the same way you would fix a spelling error. **************************************************************** From: Randy Brukardt Sent: Saturday, February 28, 2015 7:07 PM Sigh. That's what I intended to do, of course. A spelling error in ancient text (not new text) would go into a presentation AI with lots of similar fixes and eventually the ARG votes on it when we're going to produce a document or it is getting unwieldy (usually only takes a couple of minutes). I've done the same with "trivial" fixes as well, although it happens that what I think is trivial doesn't always turn out to be universal. **************************************************************** From: Jeff Cousins Sent: Monday, March 2, 2015 5:49 AM > I don't want to be the sole arbiter of whether something needs fixing, and I > surely don't want any other single individual making that call, either. I think Randy was correct to raise this, for the reason he gave, though quietly writing up a trivial AI to insert the line might have avoided another long e-mail chain. (Please don't continue it!) **************************************************************** From: Brad Moore Sent: Sunday, March 15, 2015 1:36 PM 7.3.2 (10.1/4) "After successful explicit initialization of the completion of a deferred constant with a part of type T, if the completion is inside the immediate scope of the full view of T[,] and the deferred constant is visible outside the immediate scope of T, the check is performed on the part(s) of type T;" I'm thinking comma that I've highlighted shouldn't be there. Am I right? 7.3.2 (21/4) "If performing checks is required by the Type_Invariant or Type_Invariant'Class assertion policies (see 11.4.2) in effect at the point of {the} corresponding aspect specification applicable to a given type, then the respective invariant expression is considered enabled." **************************************************************** From: Gary Dismukes Sent: Monday, March 23, 2015 8:36 PM 7.3.2 ----- Change commas as indicated below, deleting one comma and inserting two: 22.1/4 For an invariant check on a value of type T1 based on a class-wide invariant expression inherited from an ancestor type T, any operations within the invariant expression that were resolved as primitive operations of the (notional) formal derived type NT[,] are{,} in the evaluation of the invariant expression for the check on T1{,} bound to the corresponding operations of type T1. **************************************************************** From: John Barnes Sent: Saturday, March 14, 2015 9:02 AM 11.2(4.1/4). Tuck suggests changing "rather than" to "instead of". I am unsure as to whether I prefer "rather than" instead of "instead of" or maybe "instead of" rather than "rather than". I think we need a global vote on this linguistic nicety. In the first 100 pages of the AARM, rather than occurs 19 times whereas instead of occurs only 4 times. Annex A A 3.1.4 Sometimes we have input-output and sometimes input/output. A survey of the RM as a whole shows that input-output dominates and that the casual uses of input/output are somewhat random. I suggest that in this para we replace input/output by input-output. I tried to search for input output (without hyphen or slash) but the wretched thing found those with hyphen or slash as well. A.18.10(2/4) I would have preferred either "comprising" or "consisting of" rather than (perchance instead of) "comprising of". Fowler agrees with me. I should have noticed that at editorial review but I was grumbling about a comma then. But leave it, it's an example of the same sort of construction as "inside of ". A.18.10(3/4) I could mutter about "all of" rather than plain "all". Fowler says that including of is fairly modern (from 1800) but mostly unnecessary. All of the children sort of implies that one might consider just their arms and legs but not heads. However, all the children gives the feeling of completeness. Ignore me. But it does show that I am reading this stuff. **************************************************************** From: Gary Dismukes Sent: Tuesday, March 24, 2015 5:42 PM > A.18.10(2/4) I would have preferred either "comprising" or "consisting of" > rather than (perchance instead of) "comprising of". Fowler agrees with > me. I should have noticed that at editorial review but I was grumbling > about a comma then. But leave it, it's an example of the same sort of > construction as "inside of ". I agree that this should be just "comprising" or "consisting of" (I somewhat prefer the latter in this case). I also dislike the position of the comma in the sentence in question. I would change it as follows: "... [comprising] {consisting} of a root node[,] and a set of internal nodes{,} each of which contains an element and pointers to ..." **************************************************************** From: Randy Brukardt Sent: Tuesday, March 24, 2015 5:37 PM Ah, but that would be wrong. A root node doesn't contain an element, only internal nodes do. This wording is a bit weird in that we never say what the root node contains (that's in the next paragraph), but that's intended. John grumbled about the same thing [during editorial review, years ago - Editor.], and I pointed out that the comma you want to delete is "*very* important". He jokingly suggested that it be in bold. :-) If we used parens to show the grouping here, it would be: ... consisting of (a root node), and (a set of internal nodes each of which contains an element and pointers to ...)" Maybe adding "(see below)" would help point out the forward reference. "... [comprising] {consisting} of a root node {(see below)}, and a set of internal nodes each of which contains an element and pointers to ..." Dunno. Given that this is introductory wording of minimal value, I'd rather leave it subtle than hack around on it much more. But you'll get a chance on Thursday (since the wording is already ARG approved). **************************************************************** From: Robert Dewar Sent: Tuesday, March 24, 2015 5:42 PM > I agree that this should be just "comprising" or "consisting > of" (I somewhat prefer the latter in this case). I think you should always avoid the word comprising, because of its legal term-of-art meaning, which is including, but not limited to ... so if you want to give a list intended to be exhaustive, always use consisting of .. His fleet of cars comprising two fords and three toyotas. (his fleet actually has 72 toyota's, but the use of comprising is still legally correct). **************************************************************** From: John Barnes Sent: Wednesday, March 24, 2015 2:57 AM Maybe "and also" rather than just "and" after the bold comma would help ****************************************************************