To: J3 J3/21-140 From: Malcolm Cohen Subject: Editor's report for 21-007r1 Date: 2021-May-24 1. Introduction This is the editor's report for 21-007r1, also known as WG5 document N2184. Please do not create a revision of this paper. The papers passed at meeting 223, in numerical order, were: 21-101r1 21-121 21-103r2 21-122r2 21-106 21-126r1 21-108r1 21-127 21-115r3 21-129 21-117r3 21-132r1 21-119r1 2. Papers in order of application to the 007 21-106: Done. 21-101r1: DIFFERENT: [240:11+] "effective list item" -> "effective item". EXTRA: 13.7.2.4 B, O, and Z editing, p1, [277:31-278:1] "For output, ... For input, the" -> "The". {Delete remnant.} COMMENT: I think that "input/output list item" should be "effective item" throughout clause 13. It looks particularly bizarre in 13.4p5, where the 1st sentence says "there corresponds one effective item" and later in the sentence "except that an input/output list item". The latter is clearly wrong in the case of a complex array! COMMENT: 13.7.2.2 "specified input/output list item" should be "corresponding effective item", no? 13.7.4 "corresponding list item" should be "corresponding effective item", twice. Etc. (Actually I was looking at 18-007r1 for some of these.) Removed UTI 008. Done. 21-103r2: DIFFERENT: "does not have any" -> "has no". COMMENT: Should we say "in the intrinsic module ISO_C_BINDING" at the end? It's obvious that that is what we mean, and that we don't intend to prevent the user from having a F_C_STRING specific of his own. Done. 21-108r1: EXTRA: 19.5.2.7 Pointer definition status, p1, [526:34] "associated pointer" -> "associated data pointer" {Does not apply to procedure pointers.} COMMENT: The whole of subclause 19.5.2 could do with some careful rewriting and simplification, as it still says things multiple times. I.e., this paper improved it, but more improvement is possible. Done. 21-115r3: DIFFERENT [343:18+] This is a comma-separated list, so deleted "and" on line 18, and changed "." to ", and". DIFFERENT [432:33-34] and the next three edits, "The corresponding actual argument" -> "It". {This is how we specify requirements on the actual arguments on intrinsic procedures, e.g. see EVENT_QUERY for this exact same requirement.} Done. 21-117r3: DIFFERENT [xiii:2] "now supports" -> "supports"; inserted between SPLIT and TOKENIZE. DIFFERENT [27:28+] The first bullet is a "no longer permitted", not a "different interpretation", so needs to be a separate paragraph like we do those. "be of any kind type parameter" -> "be of any kind". "arguments to a particular SYSTEM_CLOCK invocation" ->"arguments of a reference to SYSTEM_CLOCK". {No need to say "particular", "a reference" is already singular.} I left "have the same kind type parameter" as is, but I wonder if we should not be saying "have the same kind" in general anyway. Greatly simplified the second bullet which expanded our vocabulary for no reason, was way too specific, and also IMO did not accurately describe what we intended. EXTRA 4.3.4 Fortran 2008 compatibility and Fortran 2003 compatibility, as the "any integer kind" feature was introduced in F2003. Basically, the same edits with minor tweaks. EXTRA Ditto Promulgated the info for the auto-reallocation-in-specifiers feature we're adding to F2008 and F2003 compatibility. EXTRA While I was in 4.3.4 Fortran 2008 compatibility, deleted "the preceding Fortran International Standard, " which is no longer true. DIFFERENT [437:5], [437:10], [437:13] (thus thrice) "equal to or greater than RANGE(0)" ->"no smaller than that of default integer" {That is how we say this.} DIFFERENT [437:14+] "arguments of type integer" -> "integer arguments". {Simpler.} COMMENT: [437:15] Reading this paragraph makes me wonder why we think there is a law against clocks on different images being in sync? You can't change the clock, so you cannot tell whether the clock is shared or in sync. This paragraph is crying out for radical simplification. REJECT [437:16] Too ugly and IMO technically broken. INSTEAD TECHNICAL CHANGE I rewrote this from scratch to say what I thought it should. In particular - we do NOT want anything to be "processor dependent" here, as that would allow the processor to select the clock based on some other criteria, like whether the number of invocations of SYSTEM_CLOCK is odd or even. I'm sure we all agree that we do not want that. - I'm not allowed to use the kind of the COUNT_RATE argument to determine the clock? Some mistake here I think, so I got rid of it in the simplification. - There is no reason to introduce another processor dependency by separating out the REAL case. - Instead, the types and kinds of the arguments determine which clock is accessed, End Of Story. - Well, not quite, because *this paragraph* is where the requirement of documentation should appear. Simplified that requirement without it losing any force. - Massively simplified the first recommendation. "ensures" -> "ensures that". REJECTED [437,21+] ISO does not permit requirements to appear in non-normative text like NOTEs (which this is). INSTEAD Inserted normative text, omitting all the witter about "many systems", with the bald requirement (recommendation) with the reason. The witter is obviously inappropriate in normative text, and just stating the reason is sufficiently informative not to need the witter anyway. REJECT [541:37+] These are already covered by the existing bullet which says that all of the values assigned by SYSTEM_CLOCK are processor-dependent. That big hammer hits everything here. Done. 21-119r1: GRUMBLE: The edits do not give the paragraph number. That makes it more annoying to check the results of the edits. Please remember! DIFFERENT After the edit, the sentence would have read: "If the coarray is an ultimate component of a polymorphic variable, the dynamic type of the variable on those images shall have the coarray component." However, the coarray component is not just in the dynamic type, but is in the Declared Type, by virtue of it actually being written in the ALLOCATE statement and not getting a compilation error. As this requirement would thus have had no effect whatsoever, I deleted the sentence instead. COMMENT In my opinion, this still does not convey the meaning and purpose of the array element restriction. Given the possibility of passing array slices as actual arguments, on the face of it this is fundamentally broken - either the restriction is actually unnecessary, or it looks like it is not sufficient to control whatever "problem" it is supposed to be addressing. Removed UTI 001. Done. 21-126r1: Done. 21-127: Done. 21-129: COMMENT: I wonder whether the two occurrences of "or may be a procedure pointer" in clause 16 (after "may be of any type") should not be "and may be a procedure pointer"? Come to think of it, some things have no type, so maybe it should be reworded? EXTRA: 7.5.4.4 Pointer components, p1, first "pointer" -> "data pointer". EXTRA: C.6.2 Pointers in expressions, p1, ditto. EXTRA: C.6.3 Pointers in variable definition contexts, p1, ditto. EXTRA: C.11.4 Pointers and targets as arguments, p2, ditto. EXTRA: Hyperlinked "pointer association" in twenty or so cases. Well, there were so many that I didn't check all of these manually, but at least LaTeX did not complain about undefined references, so it shouldn't be too bad. Done. 21-122r2: DIFFERENT [Introduction, p2+, [xiii]] Added after the intrinsic procedures and modules bullet, as I think it belongs better there. Simplified sentences and corrected grammar. DIFFERENT [4.3.3 Fortran 2018 compatibility, p2, [27:28+]] "reference of" -> "reference to" "value" -> "result" (twice) second "a number" -> "the number" (it is no longer nonspecific). DIFFERENT [17.11.16+, after IEEE_LOGB(X), [465:27+]] inserted comma after "that is" (twice). used greater-than comparisons instead of less-than, like IEEE does, deleted the witter about positive zero comparing greater than negative zero in favour of adding the missing case X=Y and signs are different: it is better to describe the effect directly, and thus avoid looking like there is an unhandled fall-through in the list. "QUIET_NAN" -> "IEEE_QUIET_NAN". COMMENT: The "X=Y and the signs are the same => either X or Y" makes a difference for decimal numbers as the "quantum" may differ; so, should this case not be designated as *processor dependent*? DIFFERENT [17.11.17 IEEE_MAX_NUM(X, Y), p6 [466:7+]] Added list item with the positive zero result, the same as for IEEE_MAX. COMMENT [17.11.17 IEEE_MAX_NUM(X, Y), p7 [466:8]] Is the processor not allowed to convert SNaN to QNaN in IEEE_MAX_NUM(SNaN,QNaN) ??? This seems a bit strange. Perhaps this should be "unless X and Y are both NaNs"? (Though that might give a different wrong impression...) EXTRA [466:21-22] 17.11.18 IEEE_MAX_NUM_MAG(X, Y), p6, Use ">" comparisons instead of "<", just like 60559 does (and it makes sense for the maximum* operations). DIFFERENT [17.11.18+, IEEE_MAX_NUM_MAG(X, Y), p8+, [466:25+]] Similar to the IEEE_MAX and IEEE_MAX_MAG changes. REJECT [17.11.19 IEEE_MIN_NUM(X, Y), p6 [467:3+]] explicitly stated the result for negative/positive zero instead. Done. 21-121: Note: I did all the OPTIONAL edits. Note: I did quite a bit of indexing of "enum type" etc. Note: Changed cross-references to the "CLASS(*) type specifier" subclause to the new "Type compatibility" subclause where appropriate. DIFFERENT [56:12+] 7.3.2.1 Type specifier syntax, , The BNF modified is not . DIFFERENT [72:15] 7.5.4.1 Component definition statement, C749, inserted comma after "intrinsic type" to improve readability. DIFFERENT [88:2-3] 7.6, "defined" -> "defines". LOCATION [90:35+] 7.8 Construction of array values, C7116, should have been [90:30-31] EXTRA EDIT: [160:20,23] 10.1.9.2 Type, type parameters, and shape of a primary, p1, Between "structure constructor," and "function reference," insert "enum constructor,". Before "If it is an array constructor" insert "If it is an enum constructor, it is scalar and its type are as described in 7.6." {We somewhat pedantically define the type/type parameters/shape of all primaries here.} COMMENT: This paragraph is a huge wall of text. Perhaps it should be turned into a bullet list? DIFFERENT [168:1-] 10.2.1.3 Interpretation of intrinsic assignments, "by the enum" -> "by the enum constructor" EXTRA [521:36+] 19.5.1.4 Host association, p2, after list item "(15) a namelist-group-name..." insert new list item "(15a) an in an ,". {Declaring an enum type blocks host association for that name.} Done. 21-132r1: DIFFERENT [152:1] Same subclause, p6 "are the same" -> "are of the same". EXTRA EDIT [160:20,23] 10.1.9.2 Type, type parameters, and shape of a primary, p1, Between "structure constructor," and "function reference," insert "enumeration constructor,". Before "If it is an array constructor" insert "If it is an enumeration constructor, it is scalar and its type are as described in 7.6.2." {We somewhat pedantically define the type/type parameters/shape of all primaries here.} DIFFERENT [272:17+] at the end of the subclause, ". The" -> "; the". {Better grammar.} DIFFERENT [277:31-278:1] 13.7.2.4 B, O, and Z editing, p1, "or of" -> ", or of" (And after a previous paper, does not need twice.) DIFFERENT [413:16+] Before 16.9.151 NINT, insert new intrinsic NEXT Deleted ", and if STAT is present, it is assigned the value zero" as it was redundant, and that text does not appear in PREVIOUS. EXTRA EDIT: [521:36+] 19.5.1.4 Host association, p2, after list item "(15) a namelist-group-name..." insert new list item "(15a) an in an ,". {Declaring an enumeration type blocks host association for that name.} COMMENT to /INTERP: It looks like the ENUMERATOR statement (either flavour) does not block host association. Done. ===END===