To: J3 J3/20-134 From: Malcolm Cohen Subject: Editor's report for new WD 20-007 Date: 2020-September-22 1. Introduction The editor applied the following papers and other changes to the base document 18-007r1 to produce the new Working Draft 20-007. New Unresolved Technical Issues have been identified. Note that one paper was rejected. ed001: Formatting/heading and other changes [Feature papers from meeting 218] ed002 19-137r2 "Specifications and Edits of AT" [US10] ed003 19-138r1 "Specification and Edits for longer statements" [US01/US02] ed004 19-139r1 "Specifications and Edits for log & friends" [US06/7/8] ed005 19-147r1 "SELECTED_LOGICAL_KIND" [US06/US07/US08] REJECTED ed006 19-149r1 "Require reports of ignorance" [US01/US02] ed007 19-156r1 "Control of leading zero in formatted numeric output" [US11] [Feature papers from meeting 219] Superseded 19-194r1 "C_F_POINTER modification for feature UK-01" ed008 19-195 "longer lines missing edit US01" ed009 19-197r3 "Edits for C_F_STRPOINTER and F_C_STRING (US09)" ed010 Re-typesetting table 16.1 following email discussion. ed011 19-203r1 "Degree trigonometric functions (US04)" ed012 19-204r1 "IEEE Circular trigonometric functions (US05)" [Feature papers from meeting 220] ed013 19-238r1 "C_F_POINTER modification for feature UK-01" ed014 19-250r1 "US 12, arrays of coarrays" ed015 19-254r2 "Edits for ISO_FORTRAN_STRINGS US03" ed016 19-255r2 "Add reductions to DO CONCURRENT (US20)" ed017 Fix typos mentioned on J3 list (three missing full stops) ed018 19-256r2, "US-23 Part 2, Standardizing use of BOZ constants" ed019 19-259r1 "Edits for Put with Notify" [US13] [Feature papers from meeting 221] ed020 20-114r1 "Edits for TYPEOF and CLASSOF" [this is US16/17/18/24] ed021 20-116r1 "Edits for SIMPLE procedures" [this is US15] ed022 Fix up summary tables in IEEE modules like the intrinsic table. ed023 20-122r1 "Edits for US14 (auto-allocate characters)" ed024 20-126r1 "Rank-agnostic allocation and pointer assignment Edits" ed025 Delete/modify UTIs after consultation. [Editorial papers from meeting 218] ed026 18-267 "Syntax errors in example codes" (m217 paper passed at m218) ed027 19-115 "Making note of Statement Entities" ed028 19-117 "Coarrays of type TEAM_TYPE" ed029 19-143 "remaining block data subprogram" ed030 19-144 "procedure pointer components" ed031 19-162r1 "C_PTRDIFF_T" [Editorial papers from meeting 219] ed032 19-165r1 "State that RECURSIVE has no semantics" ed033 19-183r3 "Clarification of global identifier" ed034 19-205 "Tweak wording in 19.4" [Editorial papers from meeting 220] ed035 19-220r1 "Editorial fix to the description of REDUCE intrinsic" ed036 19-233r1 "Minor editorial glitches" [Editorial papers from meeting 221] ed037 20-100 "Editorial fix to Example for GET_ENVIRONMENT_VARIABLE" ed038 20-102r2 "FORM TEAM and failed images" ed039 20-104r3 "Collective subroutines and STAT=" ed040 20-119 "Missing list items in 19.6.6" ed041 20-123 "Edits for procedure pointer association" ed042 Wording improvement suggested by John Reid (private communication) ***************************************************** 2. Detailed comments Specific comments that deserve further attention are identified by self- explanatory keywords in all upper case. In particular, TECHNICAL CHANGE identifies where the editor made a change to the technical contents of the standard; these should be checked by those interested to make sure that the editor's change was correct. Note: I frequently note non-major wording changes with "string"->"string". Major wording changes will have the keyword DIFFERENT. ed001: Change from interp document to 20-007, including updating the front material to say it's the fifth edition changing informal name to Fortran 202x emptying the Introduction, moving the contents into Annex C "C.1 Features that were new in Fortran 2018" adding Fortran 2018 compatibility subclause removing all the widow/orphan avoidance typesetting. ed002: 19-137r2 "Specifications and Edits of AT" [US10] 1st edit "A" -> "The". (It's definitely *the* AT edit descriptor.) [258:24] COMMENT the ordering of these edit descriptors makes little sense: - the integer ones I, B, O, Z - then the floating-point ones F, E, EN, ES, EX, - then the general one G, - then the logical one L, - then the character ones A, AT, - then the floating-point one D, - then the derived-type DT. The ordering is the same as the data-edit-desc rule, but that is not a particularly compelling reason; in my opinion, - either D should be moved in amongst the floating-point ones and G moved to the penultimate position i.e. after L,A,AT, - or just make the whole sequence alphabetic so readers have a chance to find what they are looking for. EXTRA EDIT [261:3] 13.5 Positioning by format control, p3, "an A edit descriptor" -> "an A or AT edit descriptor". DIFFERENT [261:17p1] Singularised the whole sentence. DIFFERENT [269:11] Made it a separate sentence, and... TECHNICAL CHANGE appended "; it shall not be used for input". (Without this change, a UTI would have been warranted.) NOTE: Indexed here as an edit descriptor, that is under both "AT edit descriptor" and "edit descriptor!AT. DIFFERENT [269:24+] "the AT format produces no output" -> "no output is produced by the edit descriptor". ed003: 19-138r1 "Specification and Edits for longer statements" [US01/US02] DIFFERENT: [xiii] No bullet item for "Source form", so I added one. Advertising is unnecessary, so I dropped the last part of the sentence and reworded the first part. Also I noticed there was no mention of the removal of the continuation line limit. Also the line length of fixed form is NOT being changed. All fixed by rewording. EXTRA EDIT following [49:13-14p1] Deleted "If a line contains any character that is not of default kind, the maximum number of characters allowed on the line is processor dependent." (Paper 19-149r1 also noticed and fixed this.) TECHNICAL CHANGE Guessing from the description in the intro, I am guessing that the intent is to lift the continuation line limit for fixed form as well. Every fixed-form line has exactly 72 characters (if they are of default kind), so a statement could have 15150 continuation lines in fixed form (if the first 6 chars of each continuation line don't count). [51:21-22] 6.3.3.5 Fixed form statements, p1, "A statement ... continuation lines." -> "A statement shall not have more than one million characters." ed004: 19-139r1 "Specifications and Edits for log & friends" [US06/7/8] [xiii] DIFFERENT: Added to "Intrinsic procedures and modules" where it belongs, not "Data declaration". Initially tried to reword to fix grammatical errors and insert obviously missing words, but ended up cutting it down to be minimal be completely minimal by omitting the semantics - those are specified in clause 16, the intro does not need to give details. EXTRA EDIT [429:13] 16.10.2.14 INT8, INT16, INT32, and INT64, p1, insert "named" before "constants" so that this subclause is now completely parallel to the one we just inserted and also to the REALnnn subclause. COMMENT: Most of the other named constants in ISO_FORTRAN_ENV just say "constant" not "named constant". We should make these consistent (probably by making them all "named constant"). ed005: 19-147r1 "SELECTED_LOGICAL_KIND" [US06/US07/US08] EXTRA EDIT: [xiii] "The intrinsic function SELECTED_LOGICAL_KIND returns kind type parameter values for type logical." EXTRA EDIT: [337:0+15+] Add SELECTED_LOGICAL_KIND to standard generic intrinsic table 16.1. DIFFERENT: [413:22+] "of logical type" -> "of a logical type". "that is represented by the least number of bits greater than or equal to BITS" -> "whose storage size in bits is at least BITS". Appended "If more than one kind type parameter meets the criterion, the value returned is the one with the smallest storage size, unless there are several such values, in which case the smallest of these kind values is returned." TECHNICAL CHANGE The last half of the appended sentence handles a possibility not mentioned in the paper. Unlikely though it may seem, on a processor whose Fortran LOGICAL values .FALSE. is 0 and .TRUE. is NOT(0), there could be a logical type for C interoperability that uses values compatible with _Bool, that has the same size as an existing LOGICAL type. DIFFERENT (continuing in the same place): Inserted "kind type" before "parameter values", Simplified the second half of that sentence. EDIT OMITTED: Omitted the NOTE after the example, as this now follows trivially from the normative text (assuming storage size to hold two values is +ive). ed006: 19-149r1 "Require reports of ignorance" [US01/US02] REJECTED [26:11+p2] - I disagree that the new item belongs here - it belongs after the existing item (5) about clause 6, i.e. [26:21+] - There is no indication of *when* or *how* this should be reported. - The text says "it reports when..." that would be when the programmer types it in, right? I cannot see that "when" as plausibly meaning anything else in this particular context. - A line being too long is a CONDITION not an EVENT so cannot be WHEN. - The processor is already required to have the capability of detecting and reporting this condition, as a line or statement too long is already "use within a submitted program unit of source form... not permitted by Clause 6". If a processor silently ignores extra chars that is a defect in the PROCESSOR, not in the STANDARD. - There is a long-standing convention that columns 73+ (esp. 73-80) in fixed form should be ignored (card numbers). The standard makes no mention of this (so technically, all processors are in violation right now). This edit would make things worse, by REQUIRING the processor to report the extra characters or to accept them. - The attempted wording was very different from our existing requirements re diagnostics. I am very sympathetic to the idea of requiring "good behaviour" from the processor, however, I think this paper has too many technical details wrong (or perhaps, just not quite right). It is not clear to me how to fix these problems. Given that it appears that we already require the processor to have the capability of diagnosing overly-long lines, it is unclear if we even need any extra requirement, and if we do, just what it should be. ed007: 19-156r1 "Control of leading zero in formatted numeric output" US11 DIFFERENT [xiii] "LEADING_ZERO specifier" -> "LEADING_ZERO= specifier". "OPEN and INQUIRE" -> "OPEN and WRITE" (LEADING_ZERO= in INQUIRE does not control the leading zero mode, but it does in WRITE). Deleted "new" before "AT" as unnecessary and inconsistent. COMMENT: [217:23, 12.5.2p1, Connection modes] Added between "sign mode" and "decimal edit mode" since that's where the leading zero appears (or not). SUGGESTION: Maybe this should be a bullet list instead of prose, to make the individual modes more prominent? DIFFERENT [222:7+, 12.5.6.11+] Changed ref to 12.6.2.14 to 12.6.2.9+ instead (14 is SIGN=). GRUMBLE: As well as, magic numbers of new subclauses far away, the name of the subclause is highly relevant as that is what actually goes into the LaTeX so that pdflatex can do its renumbering magic. COMMENT: [258:27+, 13.3.2p2, Edit descriptors] The editor gratefully accepts the invitation to rearrange the order of specifiers, and extends it to reordering some of the neighbouring syntax rules. DIFFERENT PLACE: [272:29+, 13.8.3+] Actually I think the new insertion logically follows the sign mode control, so I put it there. I note that the ordering of the subclauses of 13.8 is not very good. COMMENT: There is a NOTE about if the sign mode is PLUS, the plus sign is not optional, in 13.7.2.1 Numeric editing | General rules. Perhaps there should be some similar NOTE about optional leading zero in 13.7.2.3.1 Real and complex editing | General? ed008: 19-195 "longer lines missing edit US01" DIFFERENT: [518:27-28] A.2 Processor dependencies, "allowed on a source line", The deletion of this processor dependency item is rejected, as we did not remove the PD in fixed source form. Instead, prepended "in fixed source form," & deleted the ref to 6.3.2. NOTE: I did not put this PD in "obsolescent font", even though it is only about an obsolescent feature; nothing else in Annex A is in obs font (maybe nothing else is only about an obsolescent feature?). EXTRA EDIT: As I was reading through the list looking for anything obsolescent, I spotted "the pointer association status of a pointer that has its pointer association changed in more than one iteration of a DO CONCURRENT construct, on termination of the construct (11.1.7);" This is completely wrong. The pointer association status is specified to be *undefined*. (In 11.1.7.5 Additional semantics for DO CONCURRENT constructs, p4, 4th bullet.) That is not a processor-dependent status. I just went ahead and deleted this incorrect statement. ed009: 19-197r3 "Edits for C_F_STRPOINTER and F_C_STRING (US09)" DIFFERENT: [xiii] Inserted the definite article before "intrinsic module". Changed "NUL" to "null" (the former is just wrong - both the C and Fortran standards call these "null-terminated strings"). COMMENT and SUGGESTION: I don't like "to assist in the use of NUL-terminated strings", I would prefer "for conversions between Fortran CHARACTER and null-terminated C strings" (the null-terminated strings are TYPE(C_PTR) so I think it's fair to say "C string"). BUT I did not make that change at this time. DIFFERENT: [472:25+, 18.2.3.4+] Inserted "or" between the two forms of C_F_STRPOINTER, and made it run-on (i.e. no line break), as we don't do that elsewhere. In the description, "with a string" -> "with a C string" ("string" is too vague, and misleading as otherwise pointer assignment does this; perhaps "null-terminated" would be okay, but since the purpose is for C strings, let's use that?) In arg CSTRARRAY, "It is INTENT(IN)." -> "It is an INTENT (IN) argument." "rank-1" -> "rank one" (do we even have rank minus-one arrays?) ", and with" -> ", with" "of 1" -> "equal to one". The actual argument can't have the CONTIGUOUS attribute unless it is assumed-shape or a POINTER, so I changed it to a requirement that it is "simply contiguous". In arg CSTRPTR, I had lots of comments and changes, but ended up rewriting from scratch as there were too many unfixable errors In arg NCHARS, "shall be a nonnegative scalar integer" -> "shall be an integer scalar with a nonnegative value" "It is INTENT(IN)." -> "It is an INTENT (IN) argument." EXTRA EDIT: [somewhere in clause 18] "contiguous storage sequence" -> "storage sequence" (because "storage sequence" is a defined term that includes "contiguous" already). You don't need to know where that edit was made. TECHNICAL CHANGE: Completely wrote arg CSTRPTR, as "character storage units" are only for default char, so C_CHAR might have "unspecified storage units". Used array terminology instead. TECHNICAL CHANGE: Specified that CSTRPTR points to NCHARS characters i.e. whatever it is pointing to cannot be any shorter than NCHARS. TECHNICAL CHANGE: In arg NCHARS, added "If CSTRARRAY appears, NCHARS shall not be greater than the size of CSTRARRAY." COMMENT and SUGGESTION/RECOMMENDATION: The wording would have been a bit simpler if assumed-size were excluded, and NCHARS not permitted for the array case, i.e. if the first form were simply C_F_STRPOINTER(CSTRARRAY,FSTRPTR). This would lose no functionality whatsoever, as one can simply write C_F_STRPOINTER(A(:N),FP) instead of C_F_STRPOINTER(A,FP,N) This possible technical change (simplification) should be considered. DIFFERENT: [473:35+, 18.2.3.7+] "Copy a string with appended NUL" -> "String with appended null character" (verb inappropriate for function. Spell "null character" correctly.) "the length of STRING less the number of trailing blanks in STRING" -> "LEN_TRIM (STRING)" (if we're going to use Fortran instead of prose in the first sentence, we should use Fortran instead of prose in the second). Put the description of the length type parameter into Result Characteristics where it belongs. Simplify (two cases are not needed) the Result Value description and use prose instead of an indigestible untypesettable Fortran lump. TECHNICAL CHANGE: C_F_STRPOINTER only works for kind C_CHAR, so changed F_C_STRING to also only work for kind C_CHAR. (I think they should be symmetric in their kind handling.) UNRESOLVED TECHNICAL ISSUE: 017 C_CHAR could be equal to -1; in that case, are the generics nonexistent, empty, or processor-dependent whether nonexistent or empty? (It's a fairly minor issue, so I wasn't going to make this a UTI, but since we have some, and it should be fixed, I went back and added it). TECHNICAL COMMENT: I really don't like ASIS argument here. When I'm processing text, I set the length correctly. I don't want the runtime behind my back randomly trimming blanks, which it will do if I forget to write ",.TRUE." in any ref to C_F_STRING. Well, I guess that just makes it useless, as F_C_STRING(STRING,.TRUE.) is both longer and less clear than STRING//C_NULL_CHAR which invites the question, why have ASIS at all? That is, I suggest deleting the ASIS argument and just doing the trimmed case (what is currently ASIS=.FALSE.). MINOR TECHNICAL COMMENT: CSTRARRAY and CSTRPTR are horrible and unpronounceable (and look even worse when LaTeX breaks them across two lines). How about CSARRAY and CSPTR? These are shorter and not more cryptic. Or, dare I say it, CSTRING and permit CSTRING to be an array of C_CHAR or a scalar C_PTR. FSTRPTR could just be FSTRING. Or FSPTR is good too. ed010 Changing table 16.1 I made lots of notes while doing this, but they are uninteresting and thus omitted from this paper. ed011: 19-203r1 DIFFERENT [xiii] Rewrote as they don't "support blah" they *are* blah functions. DIFFERENT [332:15+] Changed "Arccosine (inverse cosine)" to the ISO term "Arc cosine", because 1) we don't need to say it twice (four times in two lines!), 2) it takes too much space, two lines for some descriptions, 3) we are supposed to follow ISO standards! EDITOR: Some time, change all the others to follow the ISO names, viz "arccosine" -> "arc cosine" et al, "inverse hyperbolic cosine" -> "arc hyperbolic cosine" et al. CONSIDER: deleting the parenthesised "explanations for the hard-of-thinking", as if they don't know "arc" === "inverse", they won't know what hyperbolic sine is in the first place! COMMENT: [333] The paper implied adding ATAND then ATAN2D to the table; I added them in alphabetic order. DIFFERENT: [340:27+, 16.9.4+] "arccos(X)" -> "the arc cosine of X" (this is correct, there is no antecedent for "arccos"). "The result is expressed" -> "It is expressed". (If "It" was good enough for ACOS, it's good enough for ACOSD.) DIFFERENT: All of them have similar modifications to the above for ACOSD. DIFFERENT: [ATAN2D] The result value description for ATAN2D is terrible. I appreciate that ATAN2 is pretty bad, but you just can't have essential conditionals in parenthetical remarks. I tried rewording this, but then considered that repeating all the edge cases is a bad idea anyway, so replaced the description with the bland "= ATAN2(Y,X)*180/pi". TECHNICAL COMMENT: Every value is "approximately 180", so these statements contribute nothing normative, they are just suggestions. We had to say "approximately" for ATAN2 et al, as pi is not represent- able in most computer arithmetics, but there is no such excuse here. 180 is B'10110100", so is representable as long as the REAL kind has at least 6 bits in the (numeric model) mantissa. I do not think that that is an unreasonable requirement. So I think we should just delete the "approximately" words here. COMMENT: The LaTeX in the paper was substantially borked, but I think I fixed it correctly. EDITOR: Change ACOS similarly w.r.t. arccos. DIFFERENT: [COSD] Deleted ", regarded as a value in degrees" as it does not belong in the argument but in the result. Rewrote description as saying that the args are *regarded* (it is results that are *expressed*). DIFFERENT: [SIND/TAND] Similarly. DIFFERENT: Back in table 16.1, made the descriptions the same as they are in the subclauses; This Is A Requirement. ed012 19-204r1 "IEEE Circular trigonometric functions (US05)" DIFFERENT: Rewrote the intro. "Inverse circular cosine" -> "Circular arc cosine" et al. Instead of "1/2", made it an actual fraction (maths not Fortran). Maybe "0.5" might be better? Fractions look okay though. ATAN2PI completely rewritten similarly to ATAN2D. Put ATAN2PI into correct alphabetic order. Used "regarded as a value in half-revolutions" instead of fun(X*pi), appending "; thus funPI(X) is approximately equal to fun(X*pi)". (This appendage could be deleted, as it is merely a remark, but perhaps it is useful to those confused by "half-revolutions".) ed013 19-238r1 "C_F_POINTER modification for feature UK-01" [intro] added comma. deleted "extra". "of FPTR" -> "for FPTR". [470:24-25] "and otherwise" -> "otherwise each lower bound" [471:21-22] instead, deleted that whole sentence, as it was a duplicate of [470:24-25]. ed014 19-250r1 "US 12, arrays of coarrays" [xiii] Combined and simplified. [134:17+] "When an ALLOCATE statement is executed for which an allocate-object is a coarray, and if" -> "If" (we're already inside the "If an allocation specifies a coarray" condition here). "all active images of the current team" -> "those images" (see previous sentence). Did not insert a paragraph break. "When an ALLOCATE statement is executed for which an allocate-object is a coarray, and if" -> "If" (as before). UNRESOLVED TECHNICAL ISSUE 001 The precise meaning of some of these restrictions is a bit unclear, and it's also unclear what problem they are intended to solve, let alone whether they actually solve it. [160:1] COMMENT: Added, but this restriction does not seem to work for CLASS(*). Maybe something somewhere else is relevant here? Inserted comma after allocatable to remove ambiguity from parse. [160:10] Disagreement in number in "an array of objects with a coarray component" Instead, "or of a type with a coarray component". [198:14] Used allocate-object not allocation, as when an allocation is for an array, is not that array and is anyway definitely not a coarray. Used different wording for the DEALLOCATE statement too. [308:25-26] REJECT. This subclause is about coarray arguments. An array which has a coarray component cannot itself be a coarray. It is an ordinary dummy argument. I almost added the "or assumed rank" to the para, but I did not see anything in the specs or the Introduction text about allowing a discontiguous section of array coarray to correspond to an assumed-rank dummy coarray. That is, this appears to be a (tiny) new feature that is not introduced as such; and furthermore, a new feature that has little or nothing to do with "arrays of coarrays". INSTEAD, appended to 15.5.2.4 Ordinary dummy variables, p22, which is already talking about arrays with a coarray ultimate component), "If the dummy argument is an array with a coarray ultimate component, the corresponding actual argument shall be simply contiguous or an element of a simply contiguous array." ed015 19-254r2 "Edits for ISO_FORTRAN_STRINGS US03" GENERAL: I see the approach taken was "complicated and no obvious error" rather than "simple and obviously no error". (Actually there are many obvious errors, but I will forgive those who didn't spot them in plenary.) This intrinsic is in dire need of simplification. [xiii] "new intrinsic" -> "intrinsic subroutine". [417:18+] "of type CHARACTER" -> "of type character" multiple times. "The intrinsic SPLIT will" -> "Invocation of SPLIT will" DIFFERENT: This sentence adds nothing; as it says, it's described under SET, so can be deleted. If you want to say that the whole of STRING is going to be referenced, say that, e.g. "Invocation of SPLIT references every character of STRING.". OTOH, that is factually wrong for the POS form. So after struggling with rewording the redundant sentence, I ended up deleting it instead. (SET et al) "of the same kind" -> "with the same kind type parameter". "Every character" -> "Each character". Swapped "Two consecutive" and "A sequence", as "A sequence..." is the general rule. Then as "Two consecutive..." is merely stating a consequence, "Two" -> "Thus, two". "null (zero-length) token" -> "token with length zero". (It's not a "null token", whatever that is.) "character in STRING" -> "character of STRING". (TOKENS) What shape does the result have if it is multi-dimensional? Is that supposed to be processor-dependent? DIFFERENT: I don't think that is reasonable, so after "allocatable array" added "of rank one" "is present" is wrong because it is not an optional argument, but anyway the whole paragraph only applies when TOKENS appears (in particular, it can't have a type if it does not appear), so I just deleted the condition. "every token found in STRING is assigned, in the order found, to the next element of TOKENS" is problematic: there is no "next element" here, and no order specified for TOKENS; also "every" is superfluous. Although it's fairly clear from context that "assigned" means intrinsic assignment, added "by intrinsic assignment" to make really sure we know what we're doing. DIFFERENT: Changed the whole sentence to "The tokens in STRING are assigned by intrinsic assignment, in the order found, to the elements of TOKENS, in array element order." and moved it to the second paragraph, moving the allocation info (which needs to be done first!) to the first para. Reworded the allocation info to actually specify the bounds and length. We don't need "found" everywhere, as the description of SET defines what the tokens are. Deleted the "blank padded" sentence (covered by intrinsic assignment). If you want a NOTE, make one. It's clearly completely trivial though. Deleted "If the blank..." with prejudice. Helpful programming advice is unsuitable for normative text. If you really want to preserve this advice (and I don't see why, as I emphatically DO NOT AGREE with it) put it in a NOTE. (And it "gives permission" to do something different, which is highly improper.) (SEPARATOR) Rewrote wholesale - so many errors it's not worth listing them. TECHNICAL CHANGE: Rank one only. TECHNICAL CHANGE: I actually wrote that it gets allocated and what to. As there are N-1 delimiters, allocated it to SIZE(n-1). REJECTED: The notion that some elements don't get assigned values. You have got to be kidding. (FIRST) Inserted "and rank one." as the later discussion makes it clear the author forgot arrays can have rank>1 and forgot the full stop. Added actual semantics and value specification. TECHNICAL CHANGE: The paper left the value for a zero-length token unspecified, so I chose the obvious value. (We don't want to make it processor-dependent do we?) (LAST) Ditto. (POS) "a scalar of type integer" -> "an integer scalar". NOTE TO EDITOR: "a scalar of type integer" appears 8 times in clause 16, "an integer scalar" appears 56 times; change the former 8 to the latter form. TECHNICAL CHANGE: for backwards, require 0 "logical scalar". Reword the near-redundant waffle so it is correct (STRING is not scanned from the beginning or the end when POS appears). If the useless BACK did not appear in those forms , this waffle could be deleted. DELETED: The zero-size array allocations, which omitted SEPARATOR anyway, as they are all specified in their argument descriptions. UNRESOLVED TECHNICAL ISSUE 002 SEPARATOR is pointless in two of the three forms, as it is a simple identity in those cases, e.g. in the FIRST+LAST form, going forwards it is: STRING(LAST(i)+1:LAST(i)+1) while in the POS form it is the even simpler STRING(POS:POS) when POS is in range, and unassigned out of range. UNRESOLVED TECHNICAL ISSUE 003 Why is the BACK argument in the first two forms, it makes No Difference to the tokens found, but instead reverses the array order. We have array section notation for doing that!!! (Unnecessarily long arglists also typeset badly.) UNRESOLVED TECHNICAL ISSUE 004 The POS form of split does not necessarily identify "whole tokens", and partial token identification has uses. I placed this UTI immediately following the erroneous sentence. [Examples:] DIFFERENT: In the first two examples, deleted the PRINT statement and inserted text to just say what the intrinsic procedure did. ed016 19-255r2 "Add reductions to DO CONCURRENT (US20)" [intro] "DO CONCURRENT" -> "the DO CONCURRENT construct", "provides the ability to define" -> "specifies", "to be calculated on" -> "for". [somewhere] BNF name changes "reduce-op" -> "reduce-operation" (it is not always an "op") "function-reduce-op" -> "function-reduction-name" (is never an "op"). TECHNICAL CHANGE: Instead of creating new keywords for these function names, just added a constraint that such a name shall be the name of the standard intrinsic functions {list}. It is utterly unacceptable to make these keywords; I note that for once OpenMP got this right and describes them as intrinsic function names, not keywords. EDITORIAL CHANGES: "a scalar or array" covers every possibility, so deleted. "of type corresponding to its reduce-op as defined in Table 11.1." -> "of intrinsic type suitable for the intrinsic operation or function specified by its reduce-operation" (no need for a table). [184:43+] This is in the *MIDDLE* of paragraph two. I presume that this was inadvertent. Added at [185:4+] instead. The first suggested two bullets under "At the beginning of execution of each iteration," explicitly stated that they are referring to *before execution of the DO CONCURRENT construct* i.e. they are not about "each iteration". Moved the condition to the start of the third bullet, making all the bullets into independent sentences. Tried to disentangle the ambiguous use of the undefined term "reduction variable" by using "construct entity" and "outside variable". I might not have reproduced what people thought they were ambiguously voting for. Massive confusion of number in a paragraph referring to a single variable with REDUCE locality! Singularised everything in sight. The table does not show the *default* initialisations, it shows the actual initialisations! And it's wrong, assigning NOT(default integer) to non-default integers. And it's wrong, HUGE is not the right answer for REAL. RANT: OpenMP got this right! Yes, I went to the table in OpenMP and made this more like that. I note that all of this would actually take less space to describe in prose than in a table, but I left it as a table for now. CONSIDER: Turn the table into prose? [185:1-4] REJECTED. No, I refuse to mess with the paragraphs of a different feature. Please do not try to insert this text without asking the question of how it's going to become an i/o affector or target when it's only allowed to appear in an intrinsic assignment statement. [185:4+] Too many errors to describe. Totally reworded. I might have gotten it right. REJECTED [185:4+] which said to add a constraint requiring the designator to be contiguous. This cannot be a constraint. And what would it be a constraint on, the outside variable? OpenMP has no such requirement. The construct entity? That's up to the processor to get it right. One could have a constraint that the outside variable is *simply contiguous*, but as OpenMP doesn't require it, what's the reason for us requiring it? [185:4+] last. Too many errors to list. Completely rewrote. I got it right. You cannot seriously want to make a ANOTHER rule that elemental operations are carried out elementwise, so I left that bit out. Gave explicit permission to the processor to combine in any order, rather than merely saying they "can" be combined in any order. UNRESOLVED TECHNICAL ISSUE 005 Text does not state the bounds in the pointer case. UNRESOLVED TECHNICAL ISSUE 006 When the outside variable has POINTER, the REDUCE variable acts like it has TARGET, but is described as having POINTER with a pile of restrictions. Why is this not described simply as TARGET? UNRESOLVED TECHNICAL ISSUE 007 Why is the reduction variable re-initialised in every iteration? For the simplest scalar cases, the processor is going to be able to optimise it away, so that would not be a performance disaster, but in a more general (especially array) case, the analysis may be very difficult and that would be a performance disaster. OpenMP doesn't do this - it has per-thread variables which get initialised once per thread, not once per iteration. ed017 Typo fixing. Inserted missing full stop at the end of 3 logical literal constants. ed018 19-256r2, "US-23 Part 2, Standardizing use of BOZ constants" [intro] "may" -> "can". Deleted the second sentence, as this feature does not appear in the agreed requirements and does not produce any viable functionality. [88:23] REJECT. BOZ constants with z+1 bits, where z is the number of bits in the largest REAL or INTEGER, are not part of the agreed requirements or specifications. TECHNICAL CHANGE: Perhaps someone thought the bits were numbered from 1? [88:26] "defining a variable of type" -> "whose \si{variable} is of type" "REAL"->"real" and "INTEGER"->"integer" thrice. "type-spec specifying a type of" -> "type-spec that specifies type" "output-list-item" (there is no such thing) -> "output-item". TECHNICAL CHANGE: Deleted "corresponding to a edit descriptor of B, O, or Z" because this is not compile-time detectable. UNRESOLVED TECHNICAL ISSUE 010 Why can BOZ be used to initialise a named constant but not a variable? This is highly irregular. [89:10+] Inserted after C7114 not C1114 as the paper wrongly suggested. "then" -> "," "::" -> "" "INTEGER"->"integer" and "REAL"->"real". DIFFERENT: Rewrote second constraint from scratch. [160:12] Instead of inserting a contradiction, split into three items; one for polymorphic, one for boz, one for nonpoly = nonboz. [162:4] "INTEGER of REAL" -> "integer or real", "the can be" -> "and is", Deleted "in which case the value of". [261:38] "specify output" -> "specify the output". [262:21+] "corresponding B, O, or Z format edit descriptor" -> "B, O, or Z edit descriptor respectively" (the sentence is still a mess, but slightly better). UNRESOLVED TECHNICAL ISSUE 008 Truncation is very much not what happens in other cases, so this is very inconsistent behaviour. Not to mention it does not even work for w==0. UNRESOLVED TECHNICAL ISSUE 009 Actually, boz-literal-constant is still not allowed for B, O and Z edit descriptors. As this part of the feature is inconsistent with other parts of Fortran, and is approximately the same as using a character string in the i/o list (just put quotes/apostrophes around the payload part of the boz-literal), it raises the question of why even have this. ed019 19-259r1 "Edits for Put with Notify" [US13, missing from 20-010r1] GENERAL COMPLAINT: This paper in particular omits context and even subclause numbers. Given you must have been looking at such things in context when writing the paper, it is unreasonable not to help the editor find what you are looking at by using such things. [xiii] Rewrote. [37:33] Added comma after immediately following "or event variable". [66:9] and [66:10-11] Added alphabetically instead. [102:12-13] Added alphabetically instead. [131:7+] Declined to define notify-variable here; we do it elsewhere for e.g. team-value, stat-variable. I.e., I defined it in the NOTIFY WAIT statement. [131:10+] Similarly declined to insert the first two constraints here. When I did, removed the xref for ISO_FORTRAN_ENV as it is not needed and would stick out into the right margin. [131:10+] Rewrote the third constraint. Inserted "intrinsic" before "assignment statement", as it seems highly unlikely that permitting it in defined assignment was deliberate, seeing as how the specifier would be invalid in CALL DEFASGN(VAR,(EXPR)) which is what defined assignment is equivalent to. [131:24+] There is no such concept as "unsuccessful execution of an assignment statement". There is also no such concept "completion of execution of an assignment statement". I reworded this to simply say "and does not wait for that image to...". (Why is this normative text anyway?) TECHNICAL COMMENT: Accessing a remote image for a variable (the notify-variable) without any coindexing is HIGHLY IRREGULAR; I guess (?) it was done this way to avoid potential notification of third images viz image one defines a variable on image two and tells image three about it. I guess it is less error-prone than merely requiring the cosubscripts on the notify- variable to specify the same image as the variable being defined, but it is still horribly inconsistent with the rest of the coarray design. [133:17-19] Added alphabetically instead. [133:30-31] Added alphabetically instead. /INTERP: Why is TEAM_TYPE missing from C948 seeing as how it is in the closely-following paragraph p4 below it? An oversight? Deliberate? [198:4+] Reworded the threshold value stuff to simplify. If this were not described as a "list of actions" we'd just say the threshold value *is* rather than "is set to", which I think would be better (it's not a variable, so does not need to be "set"), but I did not change it (the same comment applies to EVENT WAIT really). TECHNICAL CHANGE WITH NO EFFECT: There was no such thing as an "unsatisfied execution of an assignment statement", and no use was made of "unsatisfied NOTIFY WAIT", so I changed the definition around totally. END TCWNO. It is a pity that because this is not an image control statement, it duplicates quite a bit of text in 11.6.11 STAT= and ERRMSG= specifiers in image control statements. Anyway, I substantially rewrote nearly everything. COMMENT TO THE EDITOR: Perhaps the STAT= and ERRMSG= specifiers should be unified instead of duplicating them all over the place. Maybe too much work? second [199:16] This fails to give permission to access the coarray, unlike the atomic/event case. That is, it uses "cannot" with no corresponding "shall not"; I just changed "cannot be reffed until" to "may be reffed". Also, it only allows reference and not definition. That seems to be wrong, so I ended up completely rewriting it. UNRESOLVED TECHNICAL ISSUE 012 The paper said that the segment-rule-ordering exception was only for coarrays, which would exclude pointer components thereof. I changed it to say "variable" (instead of "coarray"), but as that is more onerous to implement, it deserves discussion. If my guess was right, the UTI can simply be deleted. [430:22+] Deleted "sequence of". Deleted "an image selector that specifies". "with" -> "that have". p3, "change" -> "update" (that's what we called it in p2). "NOTIFY count" -> "notify count". "in an assignment statement with an image selector that specifies" -> "of". COMMENT: Why does this not say that the effect of a reference is like ATOMIC_REF? (refs are internal to the operation of NOTIFY WAIT, but we described stuff like that for events). REJECTED NOTE 2, because there are no "segments ordered by assignment statements with an image selector that specifies a NOTIFY= specifier and NOTIFY WAIT statements". Anyway, it's just a caution to the implementor that s/he needs to know what is needed, and it's spelled out properly in the Segment order rule exemption for notified-put data. [513:42+] "Successful execution" -> "Execution" (according to the normative text). Delete "an image selector that specifies". Swap the statements to improve readability. [516:29+] REJECTED. Instead [516:21] insert "notify-variable," somewhere. [520:2+] Did this at [519:41+] as the order is meant to be subclause order. ed020 20-114r1 "Edits for TYPEOF and CLASSOF" [this is US16/17/18/24] [55:27+] No, insert the constraints here, but the text at [55:29+]. Deleted " that is a" as all TYPEOF and CLASSOF specifiers are declaration-type-specs; four times. "of assumed type or intrinsic type" -> "assumed-type or of intrinsic type". "The TYPEOF type-specifier" -> "A TYPEOF type specifier" (actually just "TYPEOF" would probably be okay). Similarly CLASSOF. Singularised the "Type parameters" sentences, and changed them to "except that" clauses instead of being a plain contradiction. TECHNICAL EFFECT: "type parameters are the same as " -> "type parameter values are the same as those of ". This means that assumed are not assumed and variable do not pass on their dependencies; this matters for procedure characteristics. I.e. given CHARACTER,INTENT(IN) :: x*(n+1),y*(*) TYPEOF(x) :: x2; TYPEOF(y)::y2 is equivalent to CHARACTER :: x2*(LEN(x)), y2*(LEN(y)) not CHARACTER(n+1) x2 ! the dependency is on X, not on N CHARACTER(*) y2 ! it is not assumed. EXTRA EDIT: Added a NOTE to explain the difference between TYPEOF/CLASSOF and repeating the declaration. UNRESOLVED TECHNICAL ISSUE 013 This enables declarations that are currently invalid, and that need to remain invalid (see examples). REWROTE: I reviewed the results, and I was struck by how we say that every other type specifier specifies a (particular) type and type parameters. I was so dissatisfied with the new text saying how these are used to "declare entities" that I rewrote it from scratch. UNRESOLVED TECHNICAL ISSUE 014 TYPEOF and CLASSOF cannot be used with TYPE(*) or CLASS(*). We could make it work (careful additional edits required!) but it is unclear whether it is even useful. [93] Capitalised the first word of each comment. ed021 20-116r1 "Edits for SIMPLE procedures" [this is US15] [intro] Changed the description to "a simple procedure references or defines nonlocal variables only via its dummy arguments" as otherwise it said it could not define nonlocal variables at all. [various] Hyperlinked "pure" to the definition of "pure procedure", and "simple" to that of "simple procedure", in some edits or the vicinity thereof. [317:21+] Combined into the existing constraint instead. [323:31-324:3] Instead, simply added "a simple procedure" to the list. (Why rewrite unnecessarily?) [16.7+] In the list, simple was uppercased once and lowercased all the other times. I did not see why the uppercase one should have been, so I made that lowercase too. The list item "a type-bound procedure that is bound to a simple procedure" does not work for deferred tbps as they are not bound to anything; added a new item "a deferred type-bound procedure whose interface specifies it to be simple," ... though maybe that wording would work for non-deferred ones too, in which case we could merge them. "host associated with a variable in the host of the subprogram or use associated with a module variable" does not work because host association can operate through more than one level e.g. the host of the host. Changed to our usual phrase "accessed by use or host association". EXTRA UNRELATED EDIT: Changed the singular occurrence of "host or use association" in the standard to "use or host association" which we use frequently. Obsolescent fonted "A simple subprogram shall not contain a reference to a variable in a common block.". DELETED "A specification inquiry in a simple subprogram that is not a constant expression shall not depend on a variable that is not a local entity of the subprogram or a construct entity or statement entity of a construct or statement contained in the subprogram." as apart from being unacceptably opaque, variables accessed by use or host association *are local entities* (they are not, however, local variables). Instead, appended "that is a constant expression" to the permission to use a use/host-associated variable in a specification inquiry. [C1599b] Intrinsic procedures and module procedures always have explicit interfaces, so their exclusion here serves little purpose; and it is duplicative of 15.4.2.2 item (2), apart from the require- ment that the interface specifies simple, and of the constraint several later. Why is this constraint even here? Does it have to be such a mess? Moved the penultimate constraint up to be with the other procedural constraints (and not following an obsolescent constraint). EXTRA EDITS: [327:4] In 16.1 Classes of intrinsic procedures, "pure subroutines" -> "simple subroutines" (there are no pure intrinsic subroutines that are not simple). [332:11,13] "an elemental" -> "a simple elemental" and "pure" -> "simple". (ES and PS notations unchanged) [398:4] "Elemental subroutine" -> "Simple elemental subroutine". [440:8] "an elemental" -> "a simple elemental" Also changed C_F_STRPOINTER to be Simple. ed022 Fixed up summary tables in the IEEE modules clause, basically the same as the intrinsic summary table. ed023 20-122r1 "Edits for US14 (auto-allocate characters)" [xiii] DIFFERENT: Shortened, added "deferred-length" since it only works for that. Used errmsg-variable instead of introducing a new term never before used. I don't like "the correct" length. "an appropriate" length is better, but is it not just "the length of the explan- atory message"? Used the latter. DIFFERENT: Similarly for iomsg-variable. DIFFERENT: Similarly for the io-unit of a WRITE statement, also inserted "scalar", and "the length of the record to be written". DIFFERENT: "the argument list" of what? I guess "an intrinsic subroutine". And its not "appears". Rewrote from scratch, using "length of the data". UNRESOLVED TECHNICAL ISSUE 015 This paper made incompatible changes to the semantics of character arguments and specifiers etc., with no edit to the Compatible subclause explaining what the changes in semantics are. This is required. [139:6-7p1] DIFFERENT: "within" -> "of". [139:10-12p2] DIFFERENT: Left the comma in, as with the "as if" wording, it seems to improve the readability. However, *WHY* does this say "as if by" and not just "by"? If it said "by", the comma is definitely unnecessary. COMMENT: I am unhappy with this too-clever mind-reading that is needed in many places in the standard; yes, this time around it's mentioned in the Introduction, but no mention in the normative text where people will look for the semantcs is too bad. I would greatly prefer to have every occurrence where we are being too clever to say, even if only parenthetically, something like "if it is deferred-length and allocatable, it is allocated or reallocated to the length of xyz" (for suitable xyz). Actually I think in some places the condition might be subtly different... in any case, noting the actual semantics in the actual places seems like a good idea. [208:44-46p12] Left the comma in for now. I reiterate my above comment. [216:12-14p2] COMMENT: That is completely insufficient. The record *IS* the variable, not the data to be written, so you were saying "X becomes defined as if by intrinsic assignment of X", in the context of "X = X", which obviously does not work. DIFFERENT: Rewrote along the lines of "is assigned the characters written by intrinsic assignment" appending ", allocating or reallocating to have length equal to the number of characters written if necessary" to make it rigorous. (I note that this kind of rigor is what I want to see everywhere these new semantics are active.) [255:2-3p1] Left the comma. I reiterate my previous comment. [332:1-3p9] DIFFERENT: inserted "by intrinsic assignment". COMMENT: I reiterate my previous comment. [339:8+]} DIFFERENT: hyphenated the adjective deferred-length. SERIOUS TECHNICAL ISSUE: This is unacceptable on two fronts: 1. It is hidden away in "General" instead of appearing in every intrinsic that it affects. 2. It does not mention the special effects of these semantics. This should probably have been a UTI, but we have enough of those already. ed024 20-126r1 "Rank-agnostic allocation and pointer assignment Edits" MISSING: edit to the Introduction. I added "An ALLOCATE statement can specify the bounds of an array allocation with array expressions. A pointer assignment statement can specify lower bounds or rank remapping with array expressions." [132:14+ 9.7.1.1 Form of the ALLOCATE statement R932 ] COMMENT: I wonder if this would not be better split up as allocation is allocate-object [ allocation-shape ] [ allocation-coarray-spec ] allocation-shape is ( allocate-shape-spec-list ) or ( [ lower-bounds-expr : ] upper-bounds-expr ) allocation-coarray-spec is lbracket [ allocate-coshape-spec-list , ] [ lower-bound-expr : ] * rbracket ...or similarly without moving the brackets and parentheses down a level. EXTRA EDIT: [C939] If an allocate-object is an array, permit upper-bounds-expr to appear instead of allocate-shape-spec-list. [133:7+ 9.7.1.1 Form of the ALLOCATE statement C942+] COMMENT: It is still wrong, as it is claiming something has to be true when it does not exist. Anyway, saying "in an " is better than using magic rule numbers. DIFFERENT: Inverted and rewrote. [134:9+ 9.7.1.2 Execution of an ALLOCATE statement p1+] EXTRA EDIT: Changed "is 1" in p1 to "is one", which is preferred. DIFFERENT: "in which" -> "for which", the same as in p1. "it specifies the upper bounds for the dimensions of the array" ->"it determines the upper bounds of the array" (cf p1). "it specifies the lower" -> "it determines the lower". COMMENT: I don't like "is specified, it specifies"; ("appears, it specifies" would have been okay). DIFFERENT: However, p1 uses "determines", and thus so should p2. [164:27+ 10.2.2.2 Syntax of the pointer assignment statement R1033 ] DIFFERENT: This was too long, so I split it across two lines with bnf continuation marks. COMMENT: It might be worth refactoring this, splitting the list/array cases one level down. [165:6+ 10.2.2.2 Syntax of the pointer assignment statement C1019+] DIFFERENT: Conditionalised on lower-bounds-expr actually appearing. DIFFERENT: Deleted "If one of them is a scalar, the effect is as if it were broadcast to the same shape as the other." (This is semantic specification and does not belong in a constraint.) DIFFERENT: Added "in a pointer-assignment-stmt" and deleted the BNF number. EXTRA EDIT: C1019 permit rank to differ when upper-bounds-expr appears. [166:27-32 10.2.2.3 Data pointer assignment p9] REJECT: This has dropped the simply contiguous and other requirements. INSTEAD: Leave that paragraph as is, add a new one about the new feature. I didn't spend long trying to wordsmith it, so it is a bit waffly, but I think it's clear what we mean. COMMENT: In general it is better to leave existing features alone, otherwise it makes more work for people trying to work out what has changed, and makes more work for translation. Not to mention less chance of inadvertent errors. Thus, if it can be done, describing new features in terms of old is better than the reverse. EXTRA EDIT: You forgot to edit p10, which breaks the new feature. Changed it to permit the new feature to exist. [165:2+ 10.2.2.2 Syntax of the pointer assignment statement C1017+] DIFFERENT: This conflicts with the previous part of the new feature, viz specifying remapping with array exprs. Rewrote to avoid conflict and remove syntax rule number. [166:34 10.2.2.2 Syntax of the pointer assignment statement p10] COMMENT: Ouch. This is okay, but depends on my previous fix, plus an implicit condition that the first sentence condition applies to the whole paragraph, not just the first sentence. This is ugly, but acceptable. Bordeline acceptable is still acceptable. More wordsmithing might be a good idea if it's not too difficult. ed025. Following consultation, deleted a previous UTI (fixing the feature instead, and modified UTI 012 (doing the fix thus making the UTI a "did I get this right?" UTI). ed026 18-267 "Syntax errors in example codes" (m217/218) [374:29-30] I did the fix in the paper, but... UNRESOLVED TECHNICAL ISSUE 011 This whole example can now be replaced by a single line, as the functionality it demonstrates is subsumed by "auto-allocate intrinsic char args". [544:3] This will be replaced by the upcoming corrigendum, but I did it anyway. ed027 19-115 "Making note of Statement Entities" [88:12+] Position seems to be wrong - in the middle of hex-digit. Instead of 7.8p1+, appended as a sentence to p7, which establishes the semantics of an ac-implied-do. [110:26+] Instead, appended this to p5, whose existing last sentence establishes the semantics of a data-implied-do. Also put a full stop at the end. ed028 19-117 "Coarrays of type TEAM_TYPE" ed029 19-143 "remaining block data subprogram" [101:25, 8.5.9 "EXTERNAL attribute" p1] Also hyperlinked it to the Block data program unit subclause. ed030 19-144 "procedure pointer components" As recommended by the author, greatly simplified the definition of procedure pointer to "procedure with the POINTER attribute (ref)". I thought of inserting a NOTE saying it is either a procedure pointer component or a procedure that has explicitly been given both the EXTERNAL and POINTER attributes, but decided not to. When I checked, I found that constraint C853 did not permit procedure pointer components to exist, as it says "A procedure with the POINTER attribute shall have the EXTERNAL attribute." Fixed by inserting "named" in front of "procedure". COMMENT: I also note the last normative para of EXTERNAL attribute is not very useful (it contains the old defn). Left as is because it is only a bit misleading, not completely wrong. ed031 19-162r1 "C_PTRDIFF_T" ed032 19-165r1 "State that RECURSIVE has no semantics" [317:38+, 15.6.2.1p3 Procedures defined by subprograms, General] DIFFERENT: I don't see what ", if it appears," adds to the equation. So I deleted it. ed033 19-183r3 "Clarification of global identifier" ed034 19-205 "Tweak wording in 19.4" ed035 19-220r1 "Editorial fix to the description of REDUCE intrinsic" ed036 19-233r1 "Minor editorial glitches" ed037 20-100 "Editorial fix to Example for GET_ENVIRONMENT_VARIABLE" Not Done, as it was included in 18-267. ed038 20-102r2 "FORM TEAM and failed images" [205:7] REJECT - this is directly stated by para 6, a mere 17 lines afterwards. Either we say it here, or we say it in para 6. Not both. [513:42] Sorry, but the *"Execution"* (of a FORM TEAM statement) cannot "have a STAT= specifier". Yes, I can work out what it's trying to say, but the cognitive dissonance is strong. Split into a separate item instead. [516:7+] Minorly reworded. This is not exactly wrong, but it is bad form for this to be the only mention of something becoming undefined. (I note that these lists all started out as summary lists of normative text elsewhere.) REQUEST: Please check that this is directly stated in FORM TEAM, as that is where people will be looking for it. If it is not already there, it should be added. If the existing para 6 is kept (see [205:7] rejection), appending to that para would be very appropriate. ed039 20-104r3 "Collective subroutines and STAT=" [331:28] In 16.6 Collective subroutines, para 5, changed "and its execution is successful, it" to "on an image, and no error is detected, the STAT argument" so that the sentence became "If the STAT argument is present in a reference to a collective subroutine on an image, and no error is detected, the STAT argument is assigned the value zero." UNRESOLVED TECHNICAL ISSUE 016 This is a NEW FEATURE. And is incompletely worded. Added UTI 016. I went ahead and tried to fix all the issues I found - if I was successful, the UTI can be deleted. [331:30] Convoluted wording unnecessary once error conditions are stated to be image-specific. Totally reworded all this stuff anyway. TRIVIAL TECHNICAL CHANGE: [331:32] This paragraph has an existing flaw which I fixed, by removing the IF STAT present condition. Technically this is also a tiny new feature (no longer requiring the processor to check that any image in the current team has stopped or failed). But I did not add that to the Intro. Substantially reworded. EXTRA EDIT: Reformatted p4-p7 of 16.6 as a bullet list. It makes it *MUCH* clearer that all of those bits apply precisely when there is a STAT=, without repeating the condition repetitively. TECHNICAL CHANGE: Rewrote the stopped/failed image conditions to be errors even when STAT is absent. (This is clearly an error of omission - or rather, poor wording - in F2018. If there is any doubt about simply fixing the wording here, we should make an interp to address the issue.) [331:34] Reworded and singularised. [516:7+] DIFFERENT: Reworded from scratch to avoid terrible wording. EXTRA EDIT: Added cross-ref to 16.6 Collective subroutines to the term "collective subroutine". ed040 20-119 "Missing list items in 19.6.6" [516:7+] DIFFERENT: Completely rewrote so that they are both of the form "When [something happens], [whatever] becomes undefined." ed041 20-123 "Edits for procedure pointer association" 10.2.2.4 "Procedure pointer assignment", paragraph 1, DIFFERENT: last "associated with" -> "of" (we have "ultimate argument(s)" *of* "dummy argument(s)".) 15.5.2.9 "Actual arguments associated with dummy procedure entities", paragraph 5, page 309:21. DIFFERENT: last "associated with" -> "of" (same reason as before). ed042 Private communication with John Reid: reordered the list of possible value types for external file unit in 12.5.1 Referring to a file, p2, to make it easier to parse i.e. there is no longer a nested "or" sequence in the middle of the outer "or" sequence. ****** UNRELATED TECHNICAL COMMENT: How is the auto-allocate stuff meant to work with defined i/o? This should be stated, otherwise programs using it are not conforming. I note that there are existing omissions in how IOMSG= works, serious enough to make programs using defined i/o at all completely non-conforming. That probably deserves an interp. However, the new adddition (auto-allocate) can be fixed without waiting for any interp. NOTE: I would suggest that if a defined i/o procedure assigns a value to IOMSG=, it is the length-trimmed value that gets assigned to the allocatable variable (otherwise it's going to be blank-padded to some processor-dependent buffer length). ===END===