!standard 4.2.1(15/5) 20-10-20 AI12-0403-1/02 !standard 4.2.1(17/5) !standard 4.2.1(18/5) !standard 4.2.1(19/5) !standard 4.3.5(93/5) !standard H.4.1(2/5) !standard H.7.1(14/5) !standard H.7.1(17/5) !standard H.7.1(18/5) !class binding interpretation 20-10-15 !status work item 20-10-15 !status received 20-10-15 !priority Low !difficulty Easy !qualifier Omission !subject Presentation issues from Draft 26 review !summary Various wording issues were noted by reviewers of Draft 26. !question (1) In 4.3.5(93/5), "Add_Positional" is not defined; it should be "Append_One", right? (Yes.) (2) In 4.2.1(17/5), we have function To_Roman_Number (S : String) return Roman_Number But this function needs to have a parameter of Wide_Wide_String to meet the requirements on the profile of a String_Literal function, right? (Yes.) (3) In H.4.1(2/5), we have No_Controlled_Parts The type of this aspect is Boolean. If True, requires that the type and any descendants do not have any controlled parts. The second sentence seems awkward. Should it be reworded? (Yes.) (4) H.7.1(17/5) says: Within an operation to which a Dispatching aspect applies, any dispatching call that does not match any dispatching_operation_specifier of the dispatching operation set is checked using the Nonblocking and Global'Class aspect(s) applicable to the called dispatching operation; if there is a match, there is no checking against the Nonblocking or global aspects applicable at the point of call. Is it clear that this only refers to the call itself and not to any checks associated with the evaluation of the parameters? (No.) In particular, the parameters are still considered to be read/written, right? (Yes.) !recommendation (1) Fix as suggested. (2) Add "Wide_Wide_" in a number of places, and reformat as needed. (3) Reword to use "shall" rather than "require". (4) Merge this entire rule with H.7.1(14/5), as there is no actual Legality Rule in it anyway, and clarify that we're only talking about the checks associated with the call and not any other checks that are nearby (including those associated with the parameters). !wording Modify 4.2.1(15/5-20/5): subtype Roman_Character is {Wide_Wide_}Character with Static_Predicate => Roman_Character in 'I' | 'V' | 'X' | 'L' | 'C' | 'D' | 'M'; Max_Roman_Number : constant := 3_999; -- MMMCMXCIX type Roman_Number is range 1 .. Max_Roman_Number with String_Literal => To_Roman_Number; function To_Roman_Number (S : {Wide_Wide_}String) return Roman_Number with Pre => S'Length > 0 and then (for all Char of S => Char in Roman_Character); function To_Roman_Number (S : {Wide_Wide_}String) return Roman_Number is (declare R : constant array (Integer range <>) of Roman_Number := (for D in S'Range => Roman_Digit'Enum_Rep (Roman_Digit'{Wide_Wide_}Value (''' & S(D) & '''))); -- See 3.5.2 and 13.4 begin [for I in R'Range => (if I < R'Last and then R(I) < R(I + 1) then -1 else 1) * R(I)] 'Reduce("+", 0) ); X : Roman_Number := "III" * "IV" * "XII"; -- 144 (that is, CXLIV) Modify 4.3.5(93/5): -- Is equivalent to: V := Empty_Vector (); for Elem of M loop [Add_Positional]{Append_One} (V, Elem); end loop; Modify H.4.1(2/5): No_Controlled_Parts The type of this aspect is Boolean. If True, [requires that ]the type and any descendants {shall}[do] not have any controlled parts. If specified, the value of the expression shall be static. If not specified, the value of this aspect is False. Modify H.7.1(14/5): The dispatching operation set is identified by a set of dispatching_operation_specifiers. It indicates that the Nonblocking and global effects of dispatching calls that match one of the specifiers need not be accounted for by the Nonblocking or global aspect, but are instead to be accounted for by the invoker of the operation. A dispatching call matches a dispatching_operation_specifier if the name or prefix of the call statically denotes the same operation(s) as that of the dispatching_operation_specifier, and at least one of the objects controlling the call is denoted by, or designated by, a name that statically names the same object as that denoted by the object_name of the dispatching_operation_specifier. { }In the absence of any dispatching_operation_specifiers{, or if none of them match a dispatching call C within an operation P}, Nonblocking and global aspects checks are performed at the point of [a dispatching]{the} call {C} within [the operation]{P} using the Nonblocking and Global'Class aspects that apply to the [named] dispatching operation {named in call C}. {If there is a match, any global access or potential blocking within the subprogram body invoked by the call C is ignored at the point of call within P. Instead, when the operation P itself is invoked, Nonblocking and global aspect checks are performed presuming each named dispatching operation is called at least once (with the named object controlling the call), but similarly ignoring those dispatching calls that would match a dispatching_operation_specifier applicable at the point of invocation of P.} Delete H.7.1(17/5) and H.7.1(18/5) [these are moved above]. !discussion (See !recommendation.) !ASIS No ASIS effect. !ACATS test No ACATS tests should be needed, none of these changes change any semantics. !appendix !topic Wrong profile in 4.2.1 Examples !reference Ada 202x RM4.2.1(18/5,19/5) !from Max Reznik 20-09-14 !keywords User-Defined String Literal Wide_Wide_String !discussion In ARM 202x Draft 26 "4.2.1 User-Defined Literals" there is an example: function To_Roman_Number (S : String) return Roman_Number But its profile is incorrect, because, according to the rules above, the parameter should have Wide_Wide_String type. **************************************************************** !topic Wrong profile in 4.2.1 Examples !reference Ada 202x RM4.2.1(18/5,19/5) !from Max Reznik 20-09-14 !keywords User-Defined String Literal Wide_Wide_String !discussion In ARM 202x Draft 26 "4.2.1 User-Defined Literals" there is an example: function To_Roman_Number (S : String) return Roman_Number But its profile is incorrect, because, according to the rules above, the parameter should have Wide_Wide_String type. **************************************************************** From: Christoph Grein Sent: Wednesday, September 23, 2020 7:35 AM There is more wrong: In (19/5) Reduce("+", 0), zero does not belong to the subtype Roman_Number, so it's illegal. **************************************************************** From: Christoph Grein Sent: Wednesday, September 23, 2020 7:59 AM Oh, and also negative numbers are not in range, so also this  is illegal: (if I < R'Last and then R(I) < R(I + 1) then -1 else 1) * R(I)] **************************************************************** From: Christoph Grein Sent: Saturday, October 3, 2020 5:24 AM Hm, I withdraw my claims about the initial value 0 and factor -1 being illegal. value_type and accum_type are Roman_Number'Base, a subtype of the type of Roman_Number. **************************************************************** From: Tucker Taft Sent: Monday, October 5, 2020 9:21 AM In 4.3.5(93/5), the example should be fixed as follows: -- Is equivalent to: V := Empty_Vector (); for Elem of M loop [Add_Positional]{Append_One} (V, Elem); end loop; **************************************************************** From: Claire Dross Sent: Friday, September 18, 2020 9:54 AM [Part of Claire's RM review - Editor.] Annex H 2/5 No_Controlled_Parts The type of this aspect is Boolean. If True, requires that the type and any descendants do not have any controlled parts. >> I am not a native speaker, but the sentence seems awkward to me. Maybe >> someone could double check? **************************************************************** From: Tucker Taft Sent: Friday, September 18, 2020 10:39 AM Agreed. The word "do" could be dropped -- "If True, requires that the type and any descendants not have any controlled parts." **************************************************************** From: John Barnes Sent: Friday, September 18, 2020 5:03 PM This is awkward. I would retain the do. The English language is, I believe , somewhat flawed in this area. **************************************************************** From: Richard Wai Sent: Friday, September 18, 2020 5:14 PM I agree! I felt removing the 'do' sounded somewhat archaic. I wasn't going to chime in, but your distinguished opinion lends credibility! **************************************************************** From: Bob Duff Sent: Friday, September 18, 2020 6:09 PM > This is awkward. I would retain the do. The English language is, I > believe , somewhat flawed in this area. Which English language? ;-) To me, it reads OK with or without the "do". I think slightly better with. **************************************************************** From: John Barnes Sent: Saturday, September 19, 2020 3:58 AM Oh dear, Bob said -----Original Message----- "John Barnes" wrote: > This is awkward. I would retain the do. The English language is, I > believe , somewhat flawed in this area. Which English language? ;-) To me, it reads OK with or without the "do". I think slightly better with. ======= And Richard agreed as well. ====== To me it reads better with do. I had a problem sleeping last night thinking about do and not. In some situations we can just insert not to produce negation but in some cases we need an auxiliary verb such as do if the verbal form is normal present indicative then we need do. Thus I kill the dragon. I do not kill the dragon. We cannot say (in Modern English) I kill not the dragon. or I not kill the dragon We have to have do as an auxiliary verb. However, if we use a continuous form I am killing the dragon then we can say I am not killing the dragon. I have consulted all the books I have which is many. None address this topic. Bobby (my wife) used to work in the linguistics department of Reading University. She could try contacting some venerable academics such as David Crystal. Her first reaction to this problem was that "small children and non-native English speakers often omit do" One can waste a lot of one's life fretting over this sort of thing. In the case in hand it is made more complex by being an auxiliary clause anyway. Maybe it should be in the subjunctive. One could try translating it into Latin and then analysing the situation. I wonder what a German speaker would say. Erhard?? Do have a nice day. **************************************************************** From: Tucker Taft Sent: Saturday, September 19, 2020 7:55 AM Decency requires that Americans not use "do" in such contexts... ;-) **************************************************************** From: Jeff Cousins Sent: Saturday, September 19, 2020 5:07 AM > To me, it reads OK with or without the "do". I think slightly better with. Ditto **************************************************************** From: Erhard Ploedereder Sent: Saturday, September 19, 2020 8:59 PM > I wonder what a German speaker would say.  Erhard?? I don't think we have a comparable situation in German wrt an auxillary word in these contexts. As to my foreign D-English, I normally use the do and omit it only in rare cases, especially when the remainder is short or if it happens to save a crucial line in print ;-). And I use it for emphasis of course, as you do. The "do" also avoids the burning question whether: "Requires that the type have" or "Requires that the type has". I do not like the former, probably because, for this situation, we do have an analogy in German: "Erfordert dass der Typ X habe" (a subjunctive, since it might not) vs. "Erfordert dass der Typ X hat" (present, more assertive) The first form is theoretically more correct, but any text that contains it, is likely older than me. Nobody is using a subjunctive in this context any more. Incidently, for the example that started this: 1. Hate sentences that are not. 2. Do not like to be thrown verbal bones to catch. 3. (Know that this is often done in the RM in similar contexts.) As in "Requires that a sentence has a subject." **************************************************************** From: John Barnes Sent: Monday, September 21, 2020 5:06 AM The subjunctive is fading in Br Engilsh too. One use is in a phrase such as "If I were you I would have a large gin." rather than "If I was you... On the other hand it is very rare in the present tense. Thus "If I be good" sounds archaic, I am sure I would say "If I am good..." I think we can agree that languages both human and computer are tricky topics! **************************************************************** From: Randy Brukardt Sent: Wednesday, September 23, 2020 12:09 AM > Annex H > 2/5 No_Controlled_Parts > The type of this aspect is Boolean. If True, requires that > the type and any descendants do not have any controlled > parts. > > >> I am not a native speaker, but the sentence seems awkward to me. > >> Maybe someone could double check? Followed by a lot of non-advice which boils down to no credible direction for the editor at all. Thanks a lot guys! Anyway, this is like a restriction that applies to a single set of descendants, and as such is going to be awkward since it is combining a negative with "True". Probably the best thing to do with this one is to rearrange and make it clear this is a Legality Rule: No_Controlled_Parts The type of this aspect is Boolean. If True, the type and any descendants shall not have any controlled parts. And I got rid of the "do", making the whole discussion moot. I hope. ;-) **************************************************************** From: Claire Dross Sent: Friday, September 18, 2020 9:54 AM [From her RM review.] Annex H-7-1 17/5 Within an operation to which a Dispatching aspect applies, any dispatching call that does not match any dispatching_operation_specifier of the dispatching operation set is checked using the Nonblocking and Global'Class aspect(s) applicable to the called dispatching operation; if there is a match, there is no checking against the Nonblocking or global aspects applicable at the point of call. >> Is it clear that parameters are still considered to be read/written? should we add a comment? **************************************************************** From: Tucker Taft Sent: Friday, September 18, 2020 10:39 AM > Annex H-7-1 > > 17/5 Within an operation to which a Dispatching aspect applies, any > dispatching call that does not match any > dispatching_operation_specifier of the dispatching operation set is > checked using the Nonblocking and Global'Class aspect(s) applicable to > the called dispatching operation; if there is a match, there is no > checking against the Nonblocking or global aspects applicable at the > point of call. > >>> Is it clear that parameters are still considered to be read/written? >>> should we add a comment? Perhaps an AARM note with an example where the actual parameter is a global, indicating it should be treated as a read and/or write of that global. Normative wording could perhaps be clarified by saying "checking {of these aspects} against the ...". Hence: "Within an operation to which a Dispatching aspect applies, any dispatching call that does not match any dispatching_operation_specifier of the dispatching operation set is checked using the Nonblocking and Global'Class aspect(s) applicable to the called dispatching operation; if there is a match, there is no checking of these aspects against the Nonblocking or global aspects applicable at the point of call." **************************************************************** Editor's note: A summary of private mail between me and Tucker Taft. Randy: Humm. I think this makes it worse, because it's not at all clear what "these aspects" refer to. The noun here is "a Dispatching aspect"; I know you're not talking about that. I suspect some the confusion here is that the two parts here seem to be talking about slightly different parts of the process; the first talks about "checking" using the N and G aspects of the called operation, but doesn't say anything about what that entails, whereas the second talks about "not checking" (unidentified aspects) against some specific aspects at the point of the call. It would be better if the two halves were truly equivalent, talking about exactly the same thing. I realize that's not easy to do. The overly long version would be something like: "Within an operation to which a Dispatching aspect applies, any dispatching call that does not match any dispatching_operation_specifier of the dispatching operation set is checked {against the Nonblocking or global aspects applicable at the point of call} using the Nonblocking and Global'Class aspect(s) applicable to the called dispatching operation; if there is a match, there is no checking {of the Nonblocking and Global'Class aspect(s) applicable to the called dispatching operation} against the Nonblocking or global aspects applicable at the point of call." It might be best to mention that we're talking about the "usual" check in the first case (which of course makes it longer still): "Within an operation to which a Dispatching aspect applies, any dispatching call that does not match any dispatching_operation_specifier of the dispatching operation set is checked {in the normal way against the Nonblocking or global aspects applicable at the point of call} using the Nonblocking and Global'Class aspect(s) applicable to the called dispatching operation; if there is a match, there is no checking {of the Nonblocking and Global'Class aspect(s) applicable to the called dispatching operation} against the Nonblocking or global aspects applicable at the point of call." I suspect this can be refactored to simplify and clarify it. Perhaps: "Within an operation to which a Dispatching aspect applies, the manner in which the Nonblocking and Global'Class aspect(s) of a dispatching call are checked against the Nonblocking or global aspects applicable at the point of call depends upon the Dispatching aspect(s) that apply. In particular, for any dispatching call that does not match any dispatching_operation_specifier of the dispatching operation set the aspects are checked in the normal way; if there is a match, there is no checking of those aspects." Maybe "in the normal way" would be better phrased as "as usual"? Or more pedantically "as described elsewhere in this Standard"? Maybe there even a better way to organize this wording? Tucker: > Humm. I think this makes it worse, because it's not at all clear what > "these aspects" refer to. The noun here is "a Dispatching aspect"; I > know you're not talking about that. To me it seems pretty clear what "these aspects" refers to, since it is plural while "dispatching aspect" is singular. But perhaps we can avoid any hint of ambiguity. ... > Maybe there even a better way to organize this wording? I don't think "normally" or "usually" work very well here, so I think we should be a bit more pedantic. In fact, I would suggest we merge this legality-rule paragraph's content (and the one following) into the Static Semantics section, as they seem closely related to a Static Semantics paragraph (14/5), and there is no "shall" or "shall not" in these paragraphs anyway. Hence, I would suggest the following: Modify H.7.1(14/5): The dispatching operation set is identified by a set of dispatching_operation_specifiers. It indicates that the Nonblocking and global effects of dispatching calls that match one of the specifiers need not be accounted for by the Nonblocking or global aspect, but are instead to be accounted for by the invoker of the operation. A dispatching call matches a dispatching_operation_specifier if the name or prefix of the call statically denotes the same operation(s) as that of the dispatching_operation_specifier, and at least one of the objects controlling the call is denoted by, or designated by, a name that statically names the same object as that denoted by the object_name of the dispatching_operation_specifier. { }In the absence of any dispatching_operation_specifiers{, or if none of them match a dispatching call C within an operation P}, Nonblocking and global aspects checks are performed at the point of [a dispatching]{the} call {C} within [the operation]{P} using the Nonblocking and Global'Class aspects that apply to the [named] dispatching operation {named in call C}. {If there is a match, any global access or potential blocking within the subprogram body invoked by the call C is ignored at the point of call within P. Instead, when the operation P itself is invoked, Nonblocking and global aspect checks are performed presuming each named dispatching operation is called at least once (with the named object controlling the call), but similarly ignoring those dispatching calls that would match a dispatching_operation_specifier applicable at the point of invocation of P.} ------- Then we can delete H.7.1(17/5 and 18/5). ****************************************************************