J3/16-105 To: J3 From: Malcolm Cohen Subject: Editor's report for 16-007 Date: 2016 January 04 1. Paper list In numeric order. 15-221r1 15-228r2 15-233r2 15-242r1 15-247r1 15-222r2 15-229r1 15-234r1 15-243 15-250r1 15-225r4 15-230r2 15-238r1 15-244r1 15-251r1 15-226r4 15-231 15-240r4 15-245 15-252 15-227r3 15-232r2 15-241r2 15-246r1 15-254r1 2. Details In order of application. 15-222r2. Done without modification. 15-230r2. [intro] Deleted a comma, "the optional" -> "an optional". [362:45+] "optional" -> "the optional" [363:36+] ditto Done. 15-242r1. Done without modification. 15-232r2. Done without modification. 15-233r2. - as it happens, the earlier edits resulted in totally different page breaking, so the [66-67:1-] edit was completely unnecessary, but I did it anyway. Done. 15-234r1. Done without modfication. 15-238r1. COMMENT: I accidentally moved p6 in INTENT before NOTE 5.15, but did not revert because I think it belongs before that NOTE (and maybe before others as well, but this at least is an improvement IMO). [114:1-] "following example" -> "subprogram". Removed blank lines in the example as when I reviewed it, they just spaced it out without making it any easier to read. Done. 15-221r1. Done without modification. 15-243. Done, also properly hyperlinked "LOCK_TYPE". 15-244r1. - hyperlinked EVENT POST statement, atomic subroutine, error termination. - indexed "unordered segments". Done. 15-245. - Subclause C.2 is left with only a single subsection; this is contrary to ISO rules, therefore I have changed the single subsection into a section with a combined title. - While I was there I noticed that C.12 only had a single subsection too, so I fixed that one as well. - In 5.something POINTER attribute, deleted "For a more elaborate example see \ref{DC:The POINTER attribute}." - In 5.somethingelse TARGET attribute, deleted "For a more elaborate example see \ref{DC:The TARGET attribute}." - In 4.5.4.6 Default initialization for components, NOTE 4.35, deleted "See \ref{DC:Pointers} for an example.". Done. 15-231. Done without modification. 15-241r2. I also made a change at [221:47] which had identical wording to the other suggested changes in the vicinity. [228:4] No, this is better without a comma. [240:8] No, this does not need a comma. HOWEVER, the sentence was ungrammatical in that there was a number mismatch between the first part and the second part, so I completely rewrote it as "In all other cases, the variable specified in the PENDING= specifier is assigned the value true, no wait operations are performed, and the previously pending data transfers remain pending after the execution of the INQUIRE statement." [240:9+6] No, no comma is needed here. Done. 15-250r1. [14:29+] Did not insert full stop into the definition (not allowed). Done. 15-229r1. [302:21] Also hyperlinked and indexed INTENT(OUT) and INTENT(INOUT) in this paragraph. [312:8-9] Did not do a LaTeX comment. No-one is going to search through 39000 lines of LaTeX for this stuff. Done. 15-247r1. Also properly indexed and hyperlinked CFI_cdesc_t. Also indexed and hyperlinked "C descriptor" better. Also fixed missing "CFI_cdesc_t" in the definition of C descriptor. Also did more hyperlinking of "lock variable". Also hyperlinked references to ATOMIC_LOGICAL_KIND to its defining para. The derived type definition statement is already indexed as the TYPE statement, so instead, inserted "see ..." index entries. Added UTIs 013 and 014; these are different problems, but probably have the same fix. Unfortunately the existing text is also wrong so leaving it alone was not really an option, and fixing it looks tricky... COMMENT: Surely NOTE 5.2 is superfluous considering the normative text immediately above it? Done. 15-227r3. Done without modification. 15-251r1. Done without modification. 15-246r1. [175:7-9] "DO CONCURRENT construct" -> "DO CONCURRENT statement". [175:9+] Combined C817a and C817[b-d], moving them after C818. Rewrote substantially. Removed ", coindexed object," as a name does not have any syntax that allows it to be coindexed! COMMENT: I wonder what happens with TYPE(*) and DIMENSION(..) variables here? Do we not need to prohibit these too? Prohibiting any nonpointer nonallocatable polymorphic might be a good idea... COMMENT: C819 "The name of a variable shall not appear..." seems badly phrased (technically wrong) and needs rewording. [178:13] The new text is almost completely incomprehensible, and also wrong. There is nothing wrong with "outside variable" or variable "outside the construct" - it is perfectly clear what this means. I made the first change of this, but kept the rest as is. [178:23] Not very readable for such a simple concept. Anyway, should appearances of the "variable" not be of the "variable name"? [484:33+] I know we all love unnecessarily redundant verbiage, but it is rather taking it to extremes to list the attributes of type, type parameters, rank and shape (not to mention that all variables have shape so "(if any)" is triply redundant) and then to blanket cover everything with "attributes". As we know, "attributes" includes all of those explicitly listed things. It is also redundant to state this both in clause 8 and in clause 16 --- one of these ought to be a cross-ref to the other. Since the attributes are important to the semantics as described in clause 8, I likewise kept the attribute specification in clause 8 and put in here a reference. Unfortunately, the attribute spec is also a lie because a LOCAL thingo: (a) cannot have INTENT because it is not a dummy argument, (b) cannot have BIND (C) because it would then be the same variable as the outer one, instead of a local copy, (c) cannot have PROTECTED because it is not a module variable, (d) cannot have VALUE because it is not a dummy argument, (e) cannot have SAVE! Added UTI 015. Done. 15-225r4. [484:12] Already done by 246r1 (in a slightly different place). Done. 15-226r4. [25:10+] "in the ISO_FORTRAN_ENV intrinsic module" ->"from the intrinsic module ISO_FORTRAN_ENV". [235:25-26] "may be used" -> "can be used". [235:28] "assignments to" -> "Assignments to". [242:11-12] "and data will" -> "if data will". after "in the same order" append "as the output list in the INQUIRE statement" (otherwise we have to be "the same" as something that is not at all specified) COMMENT: I am not really satisfied with the result; further wordsmithing welcome. [244:16] "IOSTAT_EOR or IOSTAT_END" -> "IOSTAT_EOR and IOSTAT_END,". [503:35+] "The value ... (9.6.2.9)." -> "the value ... (9.6.2.9);". Done. 15-228r2. [275:19] Also appended "as specified in \ref{D11:The USE statement and use association}" to avoid contradiction. [276:19+6 NOTE 11.4] Also set "statement function definitions," in obs. Done. 15-252. Done without modification. 15-254r1. Done without modification. 15-240r4. COMMENT: We don't define "assumed-rank" by itself, only "assumed-rank dummy data object". There is therefore nothing wrong with that definition. OTOH, it might be thought advantageous to define "assumed-rank object" or "assumed-rank variable" so the term also covers the RANK DEFAULT associate name. OTTH, this would be covered fine if we changed the definition of dummy argument as I suggest below. COMMENT: 1.3.4.5 assumed-size array definition probably needs rewording. COMMENT: 1.3.64 dummy argument definition is probably wrong, as I think that a local entity that is host-associated with a dummy argument must also be classed as a dummy argument (yes, our scoping rules are set up weirdly, but now is not the time to redesign how they work - they do, usually(!), work). Maybe "... or entity that is host-associated with a dummy argument" and maybe even "...or associate name that is associated with a dummy argument"??? (This would also address the problem that otherwise the associate name in RANK DEFAULT can hardly have "all the attributes" of the dummy argument.) COMMENT: 5.5.8.5 Assumed-size array, p1, the first sentence is now ok but the rest of p1 is a bit wonky. Perhaps the first 2 sentences of this para should be reworded something like "An assumed-size array is a dummy argument array whose size is assumed from that of its associated effective argument, or the associate name of a RANK ( * ) block in a SELECT RANK construct which assumes the size from the associated. The rank and extents may differ for the assumed-size array and its associated entity; only the size of the associated entity is assumed by the array." COMMENT: Is C538 not problematic? the associate-name is not a dummy data object is it? (I don't think it fits the definition thereof...) COMMENT: Also "is declared with an assumed-rank-spec" is untrue here, no? [184:1-] "non-negative" -> "nonnegative", "select-case-rank-stmt" -> "select-rank-case-stmt", twice. Deleted unnecessary syntax rule refs in constraints (including one that was wrong or at least confusing). "Attribute of" -> "Attributes of". COMMENT: Surely "maximum rank supported by the processor" should be "15"? (Otherwise we are making nonportable programs standard, there is no need to do that - the programs can simply use the processor extension!) COMMENT: Perhaps the first example should end with an ellipsis then an END SUBROUTINE statement (for balance)? COMMENT: Perhaps the second example should not be a clumsy extension of the first but have its own SUBROUTINE (and of course, the corresponding END SUBROUTINE) statement. Done. ===END===