To: J3 J3/22-104 From: Malcolm Cohen Subject: Editor's report for 22-007 (WG5/N2191) Date: 2021-December-27 1. Introduction This is the editor's report for the draft CD. 2. Initial edits - turned WGCD on (for the CD). - 21/007r2 -> 22/007 - set target date as 12/31 - made the hyperlinks slightly darker in colour (this is a CD after all) - applied typo edit [608:37] C.11.6 Rules ensuring unambiguous generics, p20, last sentence "Rule (4)" -> "Rule (1)". It is rule (1) that catches this case, as is clear from p19. 3. Papers in numeric order 21-170r1 21-174 21-175r5 21-176 21-178 21-179r2 21-180r1 21-181 21-182r1 21-183 21-185r1 21-186 21-189r2 21-190r1 21-195 21-199r1 21-200r1 21-201r1 21-203 21-205 4. Meeting papers in order of application (order of passage) 21-170r1. DIFFERENT [230:17] "the" -> "a" for consistency. Done. 21-181. DISCUSSION re [297:5,6] This would have ended up with "The name of each item is placed in the output record followed by an equals and a list of values of the ." This does not seem quite right, as there is no "each namelist-group-object-list" end the items have their own BNF term anyway so why phrase it this way. In principle, you could have "each item in the namelist group object list" to more clearly attach the "each" to the "item", but then we have to use prose instead of the BNF , as multiple s for a namelist are concatenated into one namelist group object list. So I think it works better as to use the same BNF team at the beginning and end of the sentence, the latter with the demonstrative pronoun for clarity, viz. "The name of each is placed in the output record followed by an equals and a list of values of that ." THUS... DIFFERENT [297:5] Instead, replaced "namelist group object list item" with "" EXTRA [297:6] also replaced the immediately-preceding "the" with "that". COMMENT: I decided to leave 8.9 alone for now. EXTRA [552:11] this item was ungrammatical, with "when the value stored in the file has a different type or type parameters from that of..." because "a" (and "that") take singular and "type parameters" is plural. This could be "a different type or different type parameters" but instead I reworded that whole phrase to "when the type or type parameters of the value stored in the file differ from those of...". Done. 21-174. DIFFERENT [504:23] Instead, replaced whole first sentence "The result is of type character with the same kind type parameter as STRING." with "Character scalar of kind C_CHAR." which is much simpler, and also consistent with our style nearly everywhere else. COMMENT could replace the whole para with the single sentence "Character scalar of kind C_CHAR, with length one greater than that of STRING if ASIS is present with the value true, and one greater than the length of STRING without trailing blanks otherwise." Done. 21-185r1. Hyperlinked "segment" widely, in particular in clauses 9 and 15. Done. 21-186. Done. 21-180r1. Done. 21-201r1. REJECT [xiv:3-] I would have added the sentence to the "Input/output" bullet instead (middle of page xiii), but as half the edits were rejected, I do not think we can really claim that "clarification" has occurred. REJECT [231:8-9] Either there are only parent or child data transfer statements, in which case this achieves nothing whatsoever, or there are other data transfer statements that are not parent or child, in which case this breaks the semantics for them, as the modes will not be reset on their termination - this would be visible via INQUIRE. COMMENT [251:35] I did this, but... Use of the syntax term io-unit is unhelpful, as being separate stmts of course they has separate syntax - this is puzzling rather than clarifying. Perhaps this is where the real topic (modes at the beginning of execution of a child data transfer statement) should be *EXPLICITLY* addressed, to avoid confusion, viz instead of this sentence say something like: "As a child data transfer statement and its corresponding parent data transfer statement use the same file connection (12.5), the connection modes at the beginning of execution of the child data transfer statement are those in effect in the parent data transfer statement at the point where the child data transfer statement was invoked." I must admit that I cannot imagine how anyone could think the pre-existing text does not already require this. I can imagine someone forgetting to copy the modes from the parent i/o context, but not thinking they don't need to be copied. Done. 21-199r1. DIFFERENT [142:27] Instead inserted "that is a \termi{coarray} or " after "have a potential subobject component". DIFFERENT [143:12] "neither nor shall" -> " shall not", because a has neither a dynamic type nor a declared type, it simply specifies a single type. Also I reject the concept that requirements on type-spec should not be a constraint; we even have a constraint suitable for adding it to... EXTRA [142:5-6] C941, "or type TEAM_TYPE" -> "type TEAM_TYPE", after "ISO_FORTRAN_ENV" insert ", or a type that has a coarray potential subobject component". Done. 21-200r1. Done. 21-176. Done. 21-178. Done. 21-182r1. Done. 21-183. Done. 21-189r2. EXTRA: [156:6] Changed ref "7.4" to "7.4, 7.6" DIFFERENT [162:15+] "are converted" -> "were converted". Done. 21-190r1. EXTRA: [276:32] "edit descriptor" -> "edit descriptors". COMMENT 13.7.2.2 Integer editing, p1, last sentence. This sentence is just superfluous waffle. We could delete it, add enum to it and another sentence for enumeration, or just leave it as is. I left it as is for now. EXTRA [277:7] "item item" -> "item" (two typos in the same sentence). EXTRA [284:10] 13.7.5.1 Overview (in 13.7.5 Generalized editing), p1, "any intrinsic type" -> "enum type or any intrinsic type". Done. 21-203. EXTRA [xiii] As suggested in my editorial comment, I split "Intrinsic procedures and modules" into "Intrinsic procedures" and "Intrinsic modules". EXTRA: Also hyperlinked "Simple" in "Simple subroutine" to the definition of "simple procedure", without indexing. Done. 21-175r5. REJECT [143:32] There is nothing whatsoever wrong with the existing text. REJECT [143:34-35] This does not make sense - it's the same statement so it has the same text on all images, and since "the allocate-object is a coarray component", it follows that the dummy arguments have that component or they would have gotten compilation errors! (On all images.) EXTRA [143:34-35] "its ultimate argument (ref) shall be the same coarray on those images" ->"the ultimate arguments (ref) on those images shall be corresponding coarrays". {Objects on different images are perforce different objects - they cannot be the same object. For coarrays, we have the "corresponding coarrays", which captures what we want here.} COMMENT The existing array element stuff immediately following is also very dubious, it looks like it prohibits some corresponding coarrays from being allocated, without preventing non-corresponding coarrays from being allocated. REJECT [147:10-11] (a) The first sentence wording change just made it uglier. (b) The rest is just wrong - it started off wittering about "the coarray" with no antecedent. If it is meant to be the coarray in the previous sentence, it does not seem to make sense, as the program text is the same on all images. EXTRA [147:10-11] "its ultimate argument (ref) shall be the same coarray on those images" ->"the ultimate arguments (ref) on those images shall be corresponding coarrays". {see above} NOTE I think there may be multiple situations where you might want to require "something". I tried to list the more obvious ones, and it's clear that shoehorning all of them into a single paragraph would be counter-productive. More work is clearly needed, but this paper does not seem to be the right direction, and whatever the "right words" are it is not obvious. Are words needed here to cover deallocation of something with coarray components? Maybe not, but again, not obvious. DIFFERENT [148:7-9] Proposed sentence 1 edits resulted in "A or B or C", without any commas to aid in deciphering; I inserted some. Inserted pronoun "which" to try to improve readability further. Done. 21-205. REJECT [28:25] and [29:23] and [340:27] and [340:33]. This is an unannounced TECHNICAL CHANGE (since Fortran 2018). Either "Fortran 2018 compatibility" needs a duplicate entry and also a mention of this new "lack of feature" in the Introduction, or (preferably) F2018 needs to be corrected via interp. In any case, it is nothing to do with US-12 and is not editorial. REJECT [145:4] This is at best wrong, at worst nonsense. The components of an unallocated object do not have any allocation status. REJECT [170:24] "ultimate component" is correct. REJECT [321:15] "ultimate component" is correct. Done. 5. Additional edits Revised hyperlinking of "potential subobject component" so the entries end up under "component | potential subobject" as well. (Only affects the index unless I made a typo.) Finished on 12/27 so changed the header text. ===END===