CVS difference for ai12s/ai12-0403-1.txt
--- ai12s/ai12-0403-1.txt 2020/10/16 04:44:25 1.1
+++ ai12s/ai12-0403-1.txt 2020/10/21 04:44:45 1.2
@@ -1,8 +1,12 @@
-!standard 4.2.1(15/5) 20-10-15 AI12-0403-1/01
+!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
@@ -12,7 +16,7 @@
!subject Presentation issues from Draft 26 review
!summary
-Various presentation issues were noted by reviewers of Draft 26.
+Various wording issues were noted by reviewers of Draft 26.
!question
@@ -27,15 +31,39 @@
meet the requirements on the profile of a String_Literal function,
right? (Yes.)
-[Editor's note: More issues to be added here.]
+(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".
-[Editor's note: More issues to be added here.]
+(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
@@ -73,8 +101,46 @@
V := Empty_Vector (<estimate of size of M>); 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
@@ -82,6 +148,8 @@
!ACATS test
+No ACATS tests should be needed, none of these changes change any semantics.
+
!appendix
@@ -150,5 +218,388 @@
-- Is equivalent to:
V := Empty_Vector (<estimate of size of M>); 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).
****************************************************************
Questions? Ask the ACAA Technical Agent