J3/17-102 To: J3 From: Malcolm Cohen Subject: Editor's report for 17-007 Date: 2016 December 29 1. Introduction This is the editor's report from the construction of 17-007. 2. Edits done without papers from meeting 211 (a) This will be WG5 document N2118. (b) Fixed incorrect title for ISO/IEC/IEEE 60559. 3. Papers from meeting 211 This is in approximate order of the papers being passed. Papers for which the only comment is "Done" were applied without change (well, without deliberate change anyway). 16-240r1. Done. 16-256r1. Done. 16-241r2. COMMENT: The constraints on the arguments for BIND(C) procedures are expressed in several different styles: (1) "If is specified for a procedure,..." (2) "... of a procedure that has a proc-language-binding-spec ..." (3) "... of a procedure that has a proc-language-binding-spec". While numbers (2) and (3) are similar, number (1) is very different. It might be a good idea to review the styles to see if some of the constraints should use a different style. COMMENT: Maybe after the constraints we should have a general waffle para e.g. "A specifies that a procedure is interoperable (18.3.7 {Interoperability of procedures and procedure interfaces})." like we do for ELEMENTAL, PURE, etc. COMMENT: Reading 18.3.7, I wonder why it says "A Fortran procedure is interoperable if ..." instead of "A Fortran procedure is interoperable if and only if ..." which the preceding interoperability subclauses do for variables. Surely there is no other way a Fortran procedure can be interoperable, in which case we should say it correctly (iff). Done. 16-251r1. Done. 16-255r1. Done. 16-257r1. [62:15+9] "a numeric" -> "a as a", because all s are numeric (indeed, they are all of integer type). [77:2] Reworded entire paragraph as it was wrong, because a procedure pointer component declaration does not even have a component-attr-spec-list. After rewording, POINTER for data components hyperlinks to the component-attr-spec rule and the one for procedure pointer components hyperlinks to the proc-component-attr-spec rule. [86:13+2] "can not" -> "cannot". Done. 16-258. The suggested insertion needed so many repairs I rewrote it from scratch, starting with the text in 7.4.3.3. Done. 16-260r1. Done. 16-242r1. I found the text "with the other images that have the same value of TEAM_NUMBER() for the team specified in the CHANGE TEAM statement" very hard to understand, not to mention ambiguous, so I changed it to "with the other images that will be in the same team after execution of the CHANGE TEAM statement" which is what I think it was trying to say. ACTION: Please check that I got it right. If alternative wording is desired, that is fine but it needs to be easier to understand than 242r1. Also: "Synchronization of these same images occurs when" ->"Synchronization of these images occurs again when" Also: "If it is desired that these synchronizations involve all of the images" ->"If it is desired to synchronize all of the images" since there is no normative text to say that inserting SYNC ALL would make the CHANGE TEAM (or END TEAM) synchronizations act differently; it is literally an extra synchronization (though the implementation *might* be able to combine them in some way). Furthermore, "should be" -> "can be" "should immediately" -> "could immediately" (we should not be making recommendations in a NOTE); different auxiliaries (can/could) used because of different surrounding wording. Finally, broke this into two paragraphs, one on what happens, one on the programming advice. Done. 16-244. I agree that this solves UTI 27, so that is now deleted. Done. 16-277r1. EXTRA EDIT: [intro] Added a sentence (a paragraph actually) about this to the Introduction. Also noticed lack of hyperindexing of some intrinsic module names in the Introduction and did those. Done. 16-282r2. EXTRA EDIT: Throughout 11.6.11 STAT= and ERRMSG= specifiers in image control statements, "specified variable"/"variable specified by the STAT= specifier" ->"". EXTRA EDIT: p5 "STAT= specifier appears in a [list of stmts]" ->"STAT= specifier appears in a in a [list of stmts]" as otherwise there is a problem with coindexed references that have a STAT= specifier (which is not, luckily, a ). COMMENT: Perhaps this could be shorted to "the STAT= " ??? QUESTION: In p3, should the list of exclusions not include STAT_*LOCKED*? Or are we just leaving that up to Quality of Implementation??? EXTRA EDIT [215:27-28] added ", STAT_UNLOCKED_FAILED_IMAGE" to the list of named constants we get from ISO_FORTRAN_ENV, and sorted it into alphabetic order. ACTUALLY: That edit went away when I revised it, see below. TECHNICAL CHANGE/EXTRA EDIT [215:30-31] Ditto, which has technical effect. EDITS REVISED: On reviewing the new p7, multiple glitches found: - the first two sentences contradict each other when an image tries to re-lock a lock variable that is on a failed image, - similarly for UNLOCK, - inconsistent layout for refs, sometimes immediately after the constant name, sometimes after the module name. ...revised by splitting the new p7 into several paragraphs and making the layout more consistent. [215:34] "another" -> "any other" UTI 031 removed. [445:38+] "an LOCK" -> "a LOCK" COMMENT: In subclause 11.6.11, there seems to be a few "the STAT=" which probably ought to be "a STAT=". COMMENT: I think I got the revisions right, but as there were a lot, this needs to be checked. Done. 16-250r1. [5:6-8] "abstract interface" also properly indexed as the definition of "interface!abstract" (the references to it were already correct). [18:29] "3.115.4 module procedure" COMMENT: I think a cross-ref to "14.2 Modules" might be better than a ref to R1408 module-subprogram for this. [19:25] Also hyperlinked "defined operation". Done. 16-254r1. [7:37-41 3.19 "branch target statement"] and [204:4-6 11.2.1p1 "Branch concepts"] Both of these lists were already (before this edit) deliberately Not in alphabetic order, grouping if-then-stmt with end-if-stmt etc. So the end-function-stmt et al were added to the end of the list. If you want me to sort these very long lists you will need to be more specific, in particular, tell me whether do-stmt and end-do-stmt should be together or separate. [21:10 3.136.1 "executable statement"] deleted "one of the statements" "or , or a" -> ", or", to make this fit the ISO requirements, viz "The definition shall be written in such a form that it can replace the term in its context. It shall not start with an article..." Done. 16-262r3. [184:9-10 R1109] REJECT - this is wrong. Note that includes things that are NOT s, and therefore (obviously) [ [ ]... ] is not the same as [ [ ]... ] and thus the assertion in the paper that they are the same is not correct. The rules are as they are now to avoid the parsing ambiguity in the original description (and which this edit would have reinstated). [199:12 C1150] REJECT: (a) This is an unnecessary change. (b) The "corank" of what? (c) I dislike propagating things like the maximum rank all over the standard, it just makes more work if it gets changed, and makes it more likely to be wrong later. INSTEAD: "maximum rank supported by the processor" -> "maximum possible rank of \si{selector}". [206:37-38 11.6.2p3(2)] TECHNICAL CHANGE: "association or allocation status" ->"allocation or association status, dynamic type, array bounds, shape, or a deferred type parameter value" (missing lots of things we want to prohibit!) EDITORIAL: "queried," -> "inquired about" (that is the wording we use elsewhere) COMMENT: Might it be a good idea to index "allocation status"? (I mean everywhere not just here - currently it is not indexed.) Maybe also "association status" should appear in the index not with a list of pages but as a link to "pointer association"? COMMENT: 11.6.2p3 first bullet also seems incomplete, surely "if a variable is defined on an image..." should be "if a variable is defined or becomes undefined on an image..." ??? [211:12- 11.6.7p2-] "value of the" -> "value of" (I think it reads better like this, though we are not very consistent) [211:24- 11.6.8p2-] ditto. [214:2, 4 11.6.11p1] "In an image control statement, the " ->"In an image control statement, the in a " EXTRA EDITS: "the " -> "an in a " "The " -> "The in a " [215:16 11.6.11p5(3)] REJECT: Image failure is bottom priority, this is already correctly specified. But apparently that is insufficiently easy to comprehend, so... INSTEAD: [215:13] "if one of the images involved has failed" ->"otherwise, if one of the images involved has failed" [215:16] "if no image has stopped and any other error" ->"otherwise, if any other error" (the line 13 edit is not needed for that item, but it is needed to set up the otherwise-if chain so that the final bullet can be clarified). [215:23,24-25 11.6.11p7] Looks like I already did this. [215:23,26-27,30 11.6.11p7] ditto. [535:1+ Annex A] REJECT. This processor dependency is already listed (STAT= also appears in ALLOCATE and DEALLOCATE, so it is ordered there, with cross-references to both places). Done. 16-261r1. [521:32+] This was stated wrongly and ungrammatically (it was a sentence beginning with a capital letter in the middle of a conditional relative clause!). Rewrote from scratch. Result is a little bit ugly, but I think it is right. Done. 16-267r1. Done. 16-271r1. [302:34-39] Resultant sentence had a mysterious leap from generic-spec to defined-operator, reworded to avoid that, constraint is now "C1502 (R1501) If the end-interface-stmt includes a generic-spec, the interface-stmt shall specify the same generic-spec, except that if one generic-spec has a defined-operator that is .LT., .LE., .GT., .GE., .EQ., or .NE., the other generic-spec may have a defined-operator that is the corresponding operator <, <=, >, >=, ==, or /=." Done. 16-246r1. Done. 16-253r2. [35:4+2] Using \ref would make it a hyperlink and thus blue. Both are unwanted, therefore this is hard-coded. Done. 16-264r4. [217:29 12.2.2p1 Formatted record] took the "join with previous sentence" option. [230:22+ 12.5.6.18p3+ STATUS= specifier in the OPEN statement] DIFFERENT: I could not find any normative text for this requirement, so instead of moving the note, changed it to normative text, changed "with a named file" to "if the FILE= specifier appears", and appended it to the preceding paragraph. ACTION: Check that this is not duplicative and is correct. [239:8 12.6.4.1p2(2) Data transfer sequence of operations] and [239:26 12.6.4.1p3(2) Data transfer sequence of operations] reference is "Identifying a unit" not "Identifying the unit". [245:39+ 12.6.4.8.3 Defined input/output procedures] COMMENT: The edit moved a subclause into the middle of another subclause without specifying whether this was merely the contents of the subclause, or whether the rest of the other subclause should be part of the moved subclause. I assumed the latter... ACTION: This now rather-long subclause includes many "inline" notes. These should be reviewed to see whether there is any reason for them to appear inline, or whether they could be moved to the end of the subclause without loss of clarity. [247:21+2 NOTE 12.45 Defined input/output] COMMENT: I am unconvinced that this note is useful or indeed helpfully worded, since "childness" cannot be determined at compile time, whereas the presence of ID= et al is a syntactic property. Perhaps "Note that a data transfer statement with the ID=, ..., specifier cannot be a child data transfer statement in a standard-conforming program." might be marginally more illuminative ... as is, we have the runtime horse before the compiletime cart. ACTION: Review wording of note for further improvements. [253:29+ 12.10.1p2+ Forms of the INQUIRE statement] COMMENT: I am convinced that INQUIRE by file that happens to be connected to a unit is still an inquiry about the file. Since an inquire by unit is not an inquiry about a connected unit (see previous paragraph - it is about the *connection* and the *file*), an inquiry by file must also be about the *connection* and the *file*, not about the unit as separate from the connection. "is about the connection and about the unit connected" ->"is about the connection as well as about the file". (The connection includes the unit IMO, and also according to the preceding paragraph, so this should be sufficient. Retaining the "about the file" however is imperative.) ACTION: Check for correctness. Optional edits done: [228:27 12.5.6.7p1] et al. COMMENT: Counting shows "This is a changeable mode" appears 3 times, and "It is a changeable mode" appears 3 times, so the latter is not more common (claimed by the paper). I changed them all to "If" anyway. Done. 16-266r3. [277:7-8 13.7.2.3.8p2 Input/output rounding mode] REJECT: "decimal value" appears 4 times in this paragraph and never again, so changing it only twice to "decimal or hexadecimal value" is completely ineffective in doing anything. The term used in the rest of the subclause is the perfectly cromulent term "original value". Some rewording would be useful, but this is not it. [280:15 13.7.6p3 User-defined derived type editing] REJECT: According to 12.6.3p8, "effective item" would be correct, but "list item" is wrong. However, the existing text is already correct anyway, because the effective item *must inevitably be a variable or value of derived type* (there being nothing else it could be in this context) so there is no change needed at all. [281:6-7 13.8.1.2p1 T, TL and TR editing] REJECT: (a) Edit was ambiguously phrased, but I think I sorted it out by carefully examining the line numbers... (b) The current sentence 3 in p1 is consistently worded with sentence 2 of p1. It is easier to understand if they are worded the same, since they are saying the same kind of thing. [289:28-29 13.11.3.3 Namelist input values] REJECT: Giving permission to use apostrophes or quotes in no way requires that the delimiters must be apostrophes or quotes! INSTEAD: "delimited sequence" -> "sequence", append ", delimited by apostrophes or quotes". [289:34+ NOTE 13.36 13.11.3.3 Namelist input values] REJECT: Deleting the first sentence means the second sentence lurches into discussion without saying what it is talking about. INSTEAD: Replaced the first two sentences with "The delimiters in the input form for a namelist input item of type character avoid the ambiguity that could arise between undelimited character sequences and object names." [291:21 13.11.4.3p3 Namelist output records] and [291:23 13.11.4.3p3 Namelist output records] COMMENT: I think these edits are a bit dodgy; the existing text is clear in that it does not apply to anything other than namelist formatting, but the new text is not. Also, the existing text seems a bit jumbled; surely it would make more sense to start talking about the "&namelist" (in the first output record) first, instead of in the middle of talking about the data output; the edit does not even attempt to improve this. The optional edits were not done, because in this particularly simple sentence structure, a comma is sufficient (the "otherwise" not being following by an "if" or further structure). Done. 16-284. Done. 16-276r2. [449:38+, 17.3 "The exceptions" p5+] I put the note after the paragraph it is relevant to, not before. Changed first sentence to singular. Deleted "at least", twice (we never say "if at least one of", since that is equivalent to "if one of"). [449:38++, 17.3 "The exceptions" p5++] A few wording changes. [449:38+++, 17.3 "The exceptions" p5+++] Capitalised the table title differently (to follow our usual style). "Operators" -> "Operator" "IEEE Comparison Predicate" -> "ISO/IEC/IEEE 60559:2011 comparison predicate". [449:38++++, 17.3 "The exceptions" p5++++] "may signal IEEE_INVALID if at least one of the values of the real and imaginary parts of the values being compared is a signaling NaN" ->"may signal IEEE_INVALID if the value of the real or imaginary part of either operand is a signaling NaN" EXTRA EDIT: Hyperlinked some nearby function names. Done. 16-270r1. Done. 16-273. NOTE: Previous text did not permit a dummy pointer to have assumed rank. I assume this was inadvertant. Done. 16-279r2. COMMENT: The editing instructions in this paper were not only hard to follow, but wrong in places. I probably got the intent right. [515:21 19.5.1.2p1 Argument association] Also hyperlinked some terms more consistently in this paragraph. EXTRA EDIT: "may" -> "can", as this is not permission. EXTRA EDIT: to p3, "may" -> "can", as this is not permission (one could read it as permission without contradiction, but that permission is entirely unnecessary). [521:7-12] EXTRA EDIT: "in at least one other" -> "in any other" ("at least" is inappropriate for a negative statement). [525:1,6,7+] REJECT - this would seem to be all said elsewhere, so is redundant. IMO it is also misleading (only dummy arguments have assumed type parameters) and poorly structured. I don't in principle entirely object to repeating ourselves (indeed much of clause 19 is duplicative) but these edits were not right. Since they would also appear to be unnecessary (existing text seems acceptable), I decline to fix them up at this time. Done. 16-286r2. Done. 16-287r1. [xviii Introduction] COMMENT: I am not entirely convinced we need to mention this in the intro, as it is correcting an obvious glitch that surely no-one got wrong. But I guess it does not hurt. [111:16 8.5.15p2(2) "PROTECTED attribute"] Inserted earlier into sentence as that reads slightly better. Done. 16-289. Done. 16-290. [325 1+] same subclause, NOTE 15.38 "associated with" -> "which is associated with", twice. Done. 16-281r2. EXTRA EDIT: [592:9] same edit as [596:4] COMMENT: This is not really necessary, but neither is the one at [596.4] Done. 16-249r1. [intro,p2,Data usage and computation] "The ... operations" ->"The standard intrinsic operations <, <=, >, and >= (also known as .LT., .LE., .GT., and .GE.)" "provide the" -> "provide", twice (neither is a full set of IEEE operations so "the" is inappropriate), after "/= operations" insert "(also known as .EQ. and .NE.). [intro,p2,Execution control] Actually, I put arithmetic IF at the start, so that all the DO stuff is together. Done. 16-268. [140:15-18 9.7.1.1p6 141:9-15] Moved entirety of 9.7.1.1p6 to follow 9.7.1.2p8 at 141:16+, changing the first "type parameter" to "length type parameter" (kind type parameters are constrained on the previous page to be the same, this is just to save the reader the trouble of turning the page back). Done. 16-288r1. Done. 16-291. [560:30 C.6.9p1 "EVENT_QUERY example that tolerates image failure"] EXTRA EDIT: Also, "earlier"->"later". COMMENT: It would be better to move this to follow the example that it modifies, leaving behind a forward reference if necessary. COMMENT: Comparing text 1 (kept) with text 2 (deleted)... "and caching and" is poor form. Please rewrite. "Therefore, this document" would be better than "This document". "all consistency" would be better as "consistency". A simple "is processor dependent" is better than "is deliberately left processor dependent" "can be observed" would be better as "might be observed". ACTION: Review wording as suggested above. EXTRA EDITS: Modified the "Example" subheadings to remove some of the unnecessary paragraph numbers. This has put the Example subheadings into the paragraphs instead of preceding them, if the latter is desired it could be done (on request). Done. 16-285r2. Done. 16-280r2. [324:16+] "from" -> "by". [324:26+] "from" -> "by". [326:1-] "must be"->"need to be". Done. ===END===