J3/15-220 To: J3 From: Malcolm Cohen Subject: Editor's report for 15-007r2 Date: 2015 September 10 1. Paper list This is in the order that I applied them. 15-162r1 15-193r1 15-194 15-197 15-192r2 15-200r2 15-202 15-203 15-199r1 15-204r1 15-189r2 15-180r2. 15-195r1. 15-206 section 5. 15-212r1. 2. Details 15-162r1. [157:2+] "the expression" -> "\si{expr}" because that's how we refer to it throughout these paragraphs. 15-193r1. [xviii] "ISO_C_BINDING intrinsic module" -> "intrinsic module ISO_C_BINDING", "PURE function" -> "pure function". [319:3+] "ISO_C_BINDING intrinsic module" -> "intrinsic module ISO_C_BINDING", EXTRA EDIT [455:9] "Subroutine" -> "Pure subroutine". (This is how we mark the pure subroutines in e.g. c13.) 15-194. Done without change. 15-197. Keyword-indexed LOCAL, LOCAL_INIT, SHARED, DEFAULT, NONE. Indexed "locality". [intro] made up some witter and inserted it. [179:38] inserted ";" before "\item". [180:1] Ditto. [180:3] and turned preceding "." into ";". [181:0+lots] "won't" -> "will not". EXTRA EDIT: Deleted NOTE 8.11. 192r2. [intro] No, added to "Execution control" (this did not exist before because there were no previous execution control enhancements). "STOP and ERROR STOP" -> "the STOP and ERROR STOP statements", "can now" -> "can". [189:...] Defined QUIET= as a specifier (for indexing). "QUIET is omitted" -> "QUIET= is omitted", "is specified to be false" ->"the has the value false", "signaling;" -> "signaling, and", "ERROR_UNIT (9.4.2.8)." ->"ERROR_UNIT from the intrinsic module ISO_FORTRAN_ENV (9.4.2,8);", "code be made" -> "it be made"., "QUIET is specified" ->"QUIET= appears", "is specified to be true" ->"the has the value true". 200r2. [462:6-9,15.3.7p4] both replaced and replacement "If" should have been "if", "Fortran intrinsic" -> "intrinsic" (just as clear here), "found" -> "listed". [467:6-8] Made singular. "that correspond to" -> "with (a)", "additional, positive type specifier value[s]" -> reworded to make distinctness more explicit. Deleted both UTI 008 and UTI 012 as this seems to have resolved them adequately. 202. [intro] "Intrinsic procedures and modules" not "Intrinsic functions", new sentence, not new list item, "SIGN function" -> "intrinsic function SIGN". Reworded as "The arguments ... can be of different kind. 203. [intro] "Intrinsic procedures and modules" not "Intrinsic functions", new sentence, not new list item, "EXTENDS_TYPE_OF or SAME_TYPE_AS" ->"the intrinsic functions EXTENDS_TYPE_OF and SAME_TYPE_AS". "are not required to"->"need not". 199r1. [94:9] Did as a new paragraph, as the existing one seems long. "" -> "". COMMENT: \si{derived-type-stmt} is not indexed as being any kind of statement. It should probably be indexed either as a "derived type statement" or "derived type definition statement". COMMENT: Maybe the "Identifiers ..." sentences should be reworded to be in the singular. 204r1. [intro] "effect" -> "effects", "calling" -> "invoking the intrinsic procedures", "imagess" -> "images", "is" -> "are". [330:1-2] Also, "effects" -> "effect" and "are" -> "is". 189r2. [26:29] "if a" -> "if the". [27:14-15] ditto. 15-180r2. Done without change. 15-195r1. [250:21] Also, "are not" -> "is not". [263:3-4] "However,"->"A" should have been "However, a"->"A". 15-206 section 5. Done without change. 15-207r2. "the C actual argument" -> "a C actual argument" (because we have not yet established which one we are talking about) "if the dummy argument corresponds to" ->"if the corresponding dummy argument interoperates with" (a more pedantic alternative would be "if the corresponding dummy argument would be required by 15.3.7 paragraph 2 item (5) to correspond to a C formal parameter that is a pointer to CFI_cdesc_t", but that is just too horrible; I hope the meaning of this shorter wording is adequately clear). COMMENT: 15.3.7 item (5) has 2 occurrences of CFI_cdesc_t in code font, but all other non-example occurrences are in normal font. We should make this consistent. EDIT for 15.5.1p1 (requested by the paper without wording): "an dummy argument that is allocatable, assumed-shape, assumed-rank, or a pointer" "a non-interoperable dummy variable (15.3.7)" (F2008 required the dummy to be interoperable; this is not particularly rigorous but it avoids a list, and puts in a cross-ref back to where the actual list is!) COMMENT: This uses a hyphenated "non" prefix, which is not our normal style. We do it sometimes though. COMMENT: I note "non-negative" is used a few times, though we mostly use "nonnegative". This should be fixed. 15-212r1. [324:22+] "If the atomic variable" -> "If a variable" (there is no concrete variable here, it is a hypothetical; and we have no concept of "atomic variables"!) changed initial X[A] to "X on image A", actually, changed A/B/C to P/Q/R in italics (cf preceding paragraph - we more often use P/Q for images) "no other image defines X[A]" ->"no other image defines X[A] in an unordered segment" (I believe this is what was meant - there can be no problem with defining X[A] in an ordered segment as that cannot interfere) "value defined by image B" ->"value assigned by image B" ("defined" just sounds wrong here, and we use "assigned" in p1 so that must be ok; "provided" or "established" would also be ok I think.) "will"->"shall" (this is supposed to be a requirement, not a pious hope) "X[A]is defined by image B and that value is received by image C" ->"the definition of X [$P$] by image $Q$ and the reception of that value by image $R$" Event edits. [incorporating 7.2 EVENT_TYPE] - deleted last sentence of opening paragraph (we do not say this for other entities defined in this module, we should not say it for this); - "atomic subroutine" -> "intrinsic subroutine"; - "during the execution" -> "during execution"; - "that coarray of type ... is defined" -> "that coarray is defined"; - ", where ATOMIC_INT_KIND is a named constant defined in" -> "from"; - "SOURCE= " -> "SOURCE= specifier"; - "The updates of atomic variables are" ->"Updates to variables via atomic subroutines are". [7.3 EVENT POST statement] - "provides a way to post" -> "posts"; - deleted "It is an image control statement." (we do not usually say this, it is said earlier so we should not say it again); - "EVENT_TYPE (7.2)" -> "EVENT_TYPE from the intrinsic module ISO_FORTRAN_ENV"; - "by 1" -> "by one". [7.4 EVENT WAIT statement] - "provides a way to wait" -> "waits"; - "events are posted" -> "an event is posted"; - deleted "It is an image control statement."; - "" -> "" ditto -list form (we already HAVE a wait-spec BNF term); - "An " -> "The "; TECHNICAL CHANGE (fix!): - "An shall not appear more than once in an ." -> "No specifier shall appear more than once in an ." END TECHNICAL CHANGE - "causes the following sequence" -> "consists of the following sequence"; - completely rewrote action (1); - "its threshold value" -> "the threshold value" (consistency); - deleted NOTE 7.4 as it was uninteresting with poor wording (that's not what my notes say though). [8.4.15 EVENT_QUERY] - "EVENT_TYPE defined in" -> "EVENT_TYPE from"; - "EVENT. Otherwise" -> "EVENT; otherwise"; - "COUNT has the value 0" -> "COUNT will have the value zero"; - "10 successful posts" -> "ten successful posts"; - "2 successful posts" -> "two successful posts"; - "UNTIL_COUNT specification" -> "UNTIL_COUNT= specifier"; - "COUNT has the value 8" -> "the variable COUNT will have the value eight". [9.2 Edits to Introduction] - rewrote. [9.3 Edits to clause 1] - deleted 1.3.8a asynchronous progress, as (1) the definition was completely useless, (2) it was only used in one place anyway, (3) and when expanded there it became even complete nonsense. [9.5 Edits to clause 4] - The text being edited had already be changed since F2008, so I made similar changes to the new text. [9.7 Edits to clause 8] - "EVENT POST and EVENT WAIT" ->"EVENT POST or EVENT WAIT statement" (consistency with existing text); - "A coarray that is of type EVENT_TYPE (ref) may be" ->"An event variable may be" (we have this defined term, let's use it!); - "that coarray of type EVENT_TYPE" -> "that event variable"; - inserted EVENT POST and EVENT WAIT subclauses immediately before LOCK and UNLOCK subclause, not before the SYNC family; [9.9 Edits to clause 13] - "Count of an event variable" -> "Query event count" (twice). [9.11 Edits to annex A] - Ignored the edit instructions to insert at the end, as these are, and are supposed to be, in subclause order. [9.12 Edits to Annex C] - Inserted A.3.1 EVENT_QUERY example under Clause 13 notes not Clause 8; - Renamed A.3.3 "EVENTS example" -> "Simple example using events"; - After "``root''" inserted "of the tree"; - "given node as parent" -> "particular node as their parent"; - "Work at a node starts" -> "Work at a node can start"; - "work at all its children" -> "all its children's work": - "data has" -> "data have"; - "children, as follows:" -> "children.". COMMENT: In 13.8.71 EVENT_QUERY, maybe "shall be scalar and of type EVENT_TYPE from the intrinsic module ISO_FORTRAN_ENV", just "shall be an event variable", since we have the defined term? Or even "shall be a nonindexed event variable"? (NB event variable => scalar already). COMMENT: If we don't do that, then EVENT_QUERY(EVENT_TYPE(),COUNT) would be valid. I do not think that is a good idea. COMMENT: The constraints on event variables allow them to be passed to procedures with implicit interfaces. I guess that is ok. COMMENT: Missing entry in "Events that cause variables to become defined" ===END===