To: J3 J3/26-125r1 From: Malcolm Cohen Subject: Editor's report for 26-007 Date: 2026-February-25 Reference: 25-007r1. 1. Introduction 26-007 is the revised Working Draft for Fortran 2028 development. It incorporates passed edits from 2025 and January 2026, plus some additional changes. 2. List of papers The following papers have been incorporated into 26-007. Subgroups should check that their edits were applied correctly, except as noted in section 3 of this report. Prior to meeting 237: m234 24-183r1 "US23/DIN4 Add generic processing of assumed-rank object" m235 25-113 US02 "Obsolete D format edit descriptor" Omitted 25-126r1, as it was overridden by 25-201r1 Omitted 25-127r1, as it was overridden by 25-202r3 Omitted 25-153r1, as it was overridden by 26-107r1 From meeting 237: 25-167 Edits to 25-007r1 25-181r1 Editorial correction re VALUE and polymorphic 25-192r2 US-01 Edits for Obsolete default implicit typing 25-193r1 US03 Edits for Note that the real model is not IEEE 754 25-197r2 US15 Readonly pointers, edits 25-199r2 Edits for US20 Collective Subroutines for Prefix Reductions 25-202r3 US04/DIN1: Edits for Asynchronous and Team Collective Subroutines 25-169r5 JP01 Edits for auto-generic subprograms 25-204r3 Consolidated edits for Templates From meeting 238: 25-201r1 US09 Allow I/O of enumeration type names 25-203r1 US05 Edits for C interchange and extended floating types 26-103r3 US20 Local Prefix Operation Intrinsics 26-106 US14 Scoped enumerator access 26-107r1 US08 Polymorphic PURE function results 26-109r2 US16 Default kinds 26-110 US25 Complex/real association 26-112 update C std refs to latest revision 3. Edits made to produce 26-007 from 25-007r1 (initial). Apart from changing the name and the dates, revised our hyperlink fixup program so that it works for bold entries in the Index. There was a LaTeX change to the format produced for the index which stopped this from working (wrong jump targets for bold Index page numbers in 25-007r1). 24-183r1 "US23/DIN4 Add generic processing of assumed-rank object" TECHNICAL PROBLEM (I did not make this a UTI, though it should be): There are technical issues with "simply contiguous" and assumed-rank and allocatable: (1) [poor wording] an assumed-rank object designator is not an array designator as it is not necessarily an array; (2) the definition is faulty for ALLOCATABLE assumed-rank; it says this is not simply contiguous (without the CONTIGUOUS attribute) - fails bullet 2, however the ultimate effective argument is always contiguous (as it is ALLOCATABLE and not assumed-rank) - which passes bullet 2. That does not make sense. (3) The CONTIGUOUS attribute is not permitted for ALLOCATABLE, except that it *IS* permitted for ALLOCATABLE assumed-rank. That does not make sense. (4) There is a contradiction with contiguous assumed-rank and scalar, as we say "an assumed-rank dummy data object whose effective argument is contiguous," but a scalar effective argument is not contiguous (only arrays can be contiguous) so this apparently means that a scalar cannot be passed to assumed-rank CONTIGUOUS. This does not make sense. RESOLUTION? (1) Low priority but perhaps after "array designator" in 9.6.4p2 insert "or assumed-rank object name". (2) Insert "nonallocatable" before "assumed-rank" in bullet 2. (3) I would prefer to disallow CONTIGUOUS with ALLOCATABLE assumed-rank, but technically that would be a backwards compatibility failure. So I guess we should leave it as is. (4) In 8.5.7 say that a scalar variable is contiguous? Or something else? END PROBLEM DESCRIPTION DIFF: Combined 1st two sentences, to factor out rank-remapping ptr assignment, after "rank-remapping pointer assignment" inserted "statement". COMMENT: Also hyperlinked polymorphic [113:36-37] 8.5.8.7 Assumed-rank entity, p1, EXTRA: Last sentence here says "An assumed-rank entity is declared with an array-spec..." but associate names are not themselves declared with an array-spec: Changed "entity" to "dummy data object". EXTRA: assumed-rank was not indexed in 8.5.8.7 which is where it is defined and where all the useful rules appear. Fixed by indexing "assumed-rank dummy data object" and "dummy data object!assumed-rank" as definitions. [114:4] Constraint C840 "An assumed-rank variable name shall not appear..." COMMENT: That was "rank-remapping pointer assignment". COMMENT: This is talking syntax viz "appear", we could, instead of "target" say "\si{data-target}" and instead of "selector" say "\si{selector}". [181:33] 10.2.2.3 Data pointer assignment, p6, COMMENT: Perhaps we should bite the bullet and say scalars are contiguous so we don't need "contiguous or scalar"? [182:1] Same subclause, before p8, insert new paragraph COMMENT: We've ended up with both "rank-remapping" and "rank-remapping pointer assignment" indexed. Perhaps just "rank-remapping"? DIFF: Omitted the spaces around the remappings, to make them more like others. [183:2-2] 10.2.2.5 Examples of pointer assignment statements, NOTE 2, Done without fixing the problems raised above. m235 25-113 US02 "Obsolete D format edit descriptor" EXTRA: Added the fact that this is now specified to be obsolescent to the Introduction. Hyperlinked to clause 13 and Annex B. DIFF editor declines to insert a paragraph in the middle of a bunch of closely related syntax rules. Appended the sentence to p2 instead. Also, "data-edit-desc"->"edit descriptor" like everywhere else in this clause. [295:15+] 13.3.2p1 Edit Descriptors DIFF As a separate paragraph, this messes up the table. It also reads a bit funny, as we're a long way into the description and then there's this whole new paragraph. Someone could read the next paragraph "input field" as applying only to D (daft as that may be). I tried it as a footnote - that puts the obsolescent callout right on the first mention of D, which seems like an improvement to me, but that messed up the table too. Appended to p1 instead, that is okay for the table. CHECK: Please read and see if you think my alternative placement is okay. If not, should it be a p2 or a footnote? (I think a footnote reads better, but I have not checked whether we are allowed normative text in a footnote. At a later date (when the text is stable) we'd probably have to move the table entirely onto the next page, but for now I'd just leave it ugly. [302:23+] 13.7.2.3.3p1+ E and D editing EXTRA unrelated edit: inserted missing full stop at the end of item (12). DIFF deleted "format" - the phrase "format edit descriptor" does not appear in the document, it is simply "edit descriptor". [598:30+] B.3.1 Obsolescent features - General DIFF Again, it is an "edit descriptor" not a "format edit descriptor". DIFF You cannot say "versions of this standard", I used "previous editions of the Fortran International Standard" same as 4.3.1. [600:26+] Done with changes. 25-167 "Edits to 25-007r1" (editorial) COMMENT "the corresponding coarrays" in 9.7.1.2, Execution of an ALLOCATE statement, para. 6. might be better as "its corresponding coarrays"? ditto for deallocation. Left as is for now. Done with no change. 25-181r1 "Editorial correction re VALUE and polymorphic" Done with no change. 25-192r2 "US-01 Edits for Obsolete default implicit typing" EXTRA: Missing edit for p599 Add new item to the list in B.3.1 "(14) Default implicit typing - see B.3.15.". DIFF: "specify mapping for initial" -> "specify the mappings for the initial" (missing articles, and all the other nouns in the sentence are plural). [601:3+] Done with changes. 25-193r1 "US03 Edits for Note that the real model is not IEEE 754" COMMENT I wonder if we shouldn't also point out that the integer model is not twos-complement. Done with no change. 25-197r2 "US15 Readonly pointers, edits" EXTRA unrelated In 8.5, moved "RANK clause" to precede "SAVE attribute". DIFF: In NOTE 2, "different value in a later execution" -> "different value in a different execution". [126:8-] 8.5 Attributes, insert new subclause alphabetically: Done with changes. 25-202r3 "US04/DIN1: Edits for Asynchronous and Team Collective Subroutines" DIFF reworded to remove redundancy and unnecessary words. [xv] Add to "Intrinsic procedures" the sentences: EXTRA in that constraint "subcomponent" -> "potential subobject component". [123:1-3, C849] Replace: DIFF Deleted "; either ..." as that is a regurgitation of what it means to be the same team. NOTE As "specified team" is used in the description of each individual collective, this needs to be specified there so that the description makes sense. IMNSHO. It's fine to have this para here as a backup, but we really don't want people flipping pages all the time. It's not like the STAT and ERRMSG args because everyone already knows what they do/ TECHNICAL raised UTI 001 for the TEAM argument. [380:30-] after paragraph 1: NOTE 25-125r1 says "The SYNC TEAM statement allows synchronization over any specified ancestor team or child team passed as a TEAM_TYPE argument, which is analogous to the feature proposed here except for data exchange instead of synchronization." BUT that restriction is not present in the edits, they permit team collectives unrelated to the current team, neither an ancestor nor a child. It could be a side-by-side team with overlapping membership, or far away in the team hierarchy tree. That does not seem to make sense. If you cannot CHANGE TEAM (or exit from CHANGE TEAMs) to reach the team, the logic is very suspect. In fact, I think that if the team is not an ancestor or child, it is not possible to satisfy para 2 "in between [team changes], the sequence of invocations of collective subroutines shall be the same on all active images of a team". Actually, even child teams do not work here; that could perhaps be fudged by inventive wording. I cannot envisage any wording that would work in p2 for unrelated teams. We really should not do that, as apart from the wording difficulties, permitting unrelated would inhibit cost-effective runtime deadlock detection. REJECT This wording just does not work. [380:32] paragraph 2: TECHNICAL raised UTI 002 about the issue. COMMENT Hey guys, separate paras mean separate edits! DIFF There is no such thing as the "current image". Replaced by the "executing image". COMMENT In para 6, we have "contains... stopped" and "contained... failed". Surely these need to be the same? [381:2,7,13,15] paragraph 3, paragraph 4 bullet 4, paragraph 6 (twice): DIFF A "call" does not "return", so "before the initiation call returns" -> "on invocation", "initiation call returns" -> "reference to the collective subroutine completes execution". Why do you need to xref 18.10.4 in both paragraphs. Deleted the second. I note that "outstanding" is a word with ambiguous meaning, and one that we have never used before in normative text. "outstanding" -> "pending" (that is the word we used for this before). DIFF "proceeds as an asynchronous input communication". No communication is mandated or implied. Yes, there are implementations with no communication. Changed to "proceeds as if it were an asynchronous input communication". DIFF Not entirely convinced that "an error condition" means it has "finished" its computation (though it has certainly stopped). Also we can have error conditions on some images and not others, so this is confusing and almost ambiguous. Also this is asynchronous, so we could have error conditions in other statements too. Reworded... I think it's an improvement. DIFF "reaches"... no transportation is mandated or implied. ->"becomes". [381:3-] after paragraph 3: DIFF "initiation call" -> "reference". "asynchronous communication" -> "asynchronous operation". "outstanding" -> "pending". etc. [381:19+] append to paragraph 7: DIFF Used different styles for the table entries here because otherwise it takes many lines with lots of ugly whitespace. [383] In 16.7 Standard generic intrinsic procedures, Table 16.1, DIFF "Wait for" -> "Wait on". [383] In 16.7 Standard generic intrinsic procedures, Table 16.1, COMMENT: All the intrinsic subroutines have "It is an INTENT (IN) argument." even though that is vacuously true for all intrinsic arguments unless otherwise specified (16.2.1). These could be deleted. In fact, these should be deleted unless we want to change 16.2.1 to apply only to intrinsic functions. EXTRA (unrelated): Improved indexing by un-indexing all the INTENT attributes in the intrinsic clause. DIFF Gave the proper description and requirements for TEAM. No, it is not good enough to say the "semantics of TEAM... are described in", because the wording "specified team" is used in the description here, and also, if TEAM does not appear, there is an effect - and that would not be covered by "the semantics of TEAM". [409:6-] before the description of STAT in paragraph 3, insert: DIFF inserted missing comma. [409:9] replace paragraph 4 with: DIFF proper description of TEAM. [409:28-] before the description of STAT in paragraph 3, insert: DIFF inserted missing comma [409:31] replace paragraph 4 with: DIFF proper description of TEAM. [410:12-] before the description of STAT in paragraph 3, insert: DIFF inserted missing comma [410:15] replace paragraph 4 with: COMMENT: Typeset in a different style so that it is readable (following the usual style it was incomprehensible). [410:19] Replace the heading with: DIFF proper desc of TEAM [411:4-] before the description of STAT in paragraph 3, insert: DIFF inserted missing comma [411:7] replace paragraph 4 with: DIFF proper desc of TEAM [411:36-] before the description of STAT in paragraph 3, insert: DIFF inserted missing comma [411:39] replace paragraph 4 with: DIFF "Wait for" -> "Wait on". deleted "when present,". We don't say that or need to say that. "logical type" -> "type logical" (there is only one type here). "reaches" -> "becomes" "be defined to" -> "become defined with" "and false" -> "and with the value false". after "initiate several asynchronous collective", "subroutines"-> "operations" REJECT "and overlap..." no normative text supports this assertion. replaced with a new sentence saying that things *can* overlap. Also, it is an operation, not a communication; the standard does not (and should not!) require there to be communication. Fixed inconsistent capitalisation in the example. Made other cosmetic improvements to the example. Reworded the NOTE. [412:14-] In 16.9 Specifications of the standard intrinsic procedures, DIFF "nonpointer subobject" -> "potential subobject component". This was copied from EVENT_TYPE. It is just wrong, because being a subobject is a runtime thing when allocatable components are involved. FIXED the other, incorrect, words. DIFF "outstanding" -> "pending". NOTE hyperlinked "variable definition context" to the subclause defining it throughout 16.10. [493:14-] Insert a new section in 16.10.2 before CURRENT_TEAM: Done with those changes. Two new UTIs. 25-199r2 "Edits for US20 Collective Subroutines for Prefix Reductions" DIFF Changed style of these table entries as the usual style is unreadable. [383] In 16.7 Standard generic intrinsic procedures, Table 16.1, DIFF Alternative style as usual is unreadable. [383] In 16.7 Standard generic intrinsic procedures, Table 16.1, DIFF Alternative form of subclause heading (we don't need to repeat the intrinsic name) to improve readability. DIFF "INITIAL shall have the same value" -> "It shall have the same value". DIFF "same type and type parameter values" -> "same type and type parameters" for consistency with CO_REDUCE. The wording here needs to be identical. DIFF proper specification for TEAM. DIFF ", STAT and ERRMSG are" -> ", STAT, and ERRMSG are". DIFF "logicals, and the logicals delineate the various segments..." ->"logicals; the logicals delineate the segments..." DIFF capitalised values, logicals, and results. "Note the" -> "Note that the". DIFF "any given image i" -> "image i", and the other "any given" -> "each". The images are not "given". DIFF "provided by" -> "on". It's the value of A "on" the other image, there is no "provisioning". DIFF Rewrote the algorithm description to simplify and remove ambiguity. COMMENT: "the number of images in the current team is " sounds clumsy, why not "the current team has images"? (yes, I know that CO_SUM was already worded like that). DIFF Deleted the keywords in the example, so that it fits within the line without too many irritating continuations. TECHNICAL COMMENT: There are no backwards compatibility issues, so we could have fewer forms, e.g. CO_REDUCE_PREFIX_EXCLUSIVE (A, OPERATION, INITIAL, [ TEAM, COMPLETION, STAT, ERRMSG]) DIFF Similar changes to CO_REDUCE_PREFIX_*. DIFF in ...INCLUSIVE, "values in corresponding elements" -> "values of..." same as ...EXCLUSIVE. [412:4-] In 16.9 Specifications of the standard intrinsic procedures, DIFF "computed value of" -> "values computed by". (more than one value, and it should always have been "by" not "of". [596:19-20] In Annex A.2 Processor dependencies, replace the following Done with lots of changes. 25-169r5 JP01 "Edits for auto-generic subprograms" EXTRA: Add NOTE to entry: "Generic subprograms are described in 15.6.2.4." because the hyperlink to prefix-spec does not take one there. [27:16+] Before 3.139.2 internal subprogram, insert new term OOPS: C713a had a comment that looked like alternative wording "shall be a derived-type-spec or generic-derived-type-spec that identifies" I just used the wording that was there and ignored the bad comment. DIFF "nonchar-intrinsic-type-name" -> "nonchar-intrinsic-type". because (a) it was too wide, (b) it's not a symbolic name, it is a keyword. COMMENT: The term "assumed type parameter" should mention that the syntax is "*", perhaps like the "deferred type parameter" says it is ":", or just as a Note to entry. [69:21-] Before 7.3.2.2 TYPE type specifier, insert new subclause COMMENT: The text about overriding char-length is a bit misleading, as it is completely pointless. Oh well. Maybe we should just forbid it rather than require it to be * or : [110:15] Same subclause, p1, after "by declaration-type-spec" NOTE Already did this as part of PROTECTED_TARGET. [126-127] 8.5.16 SAVE attribute and 8.5.17 RANK clause, DIFF "If the RANK" -> "If a RANK" (no antecedent). [127:1-2] Same subclause, C863 DIFF "are greater" -> "are both greater", "and are less" -> "and less". [127:7+] Same subclause, after para 2, insert new paragraph DIFF typo "select-generic-rank-case-stmt" -> "generic-rank-case-stmt" EXTRA Adjusted spacing for all the constructs with guards/blocks to be consistent, made sure there was a space between "]" and "...". [223:1-] Immediately before 11.1.10 SELECT RANK construct, insert new YES as suggested, turned the opaque text blob into a proper table. That includes turning the redundant requirement in clause 3 into a forward reference to the table. [228:24-28] 11.2.1 Branch concepts, p1, EXTRA generic-name is not defined (so it is just "name"), fixed by adding a constraint. EXTRA Missing constraint against generic-name when the MODULE keyword appears. (the existing constraint does not cover it, and this would be too confusing to allow). EXTRA The syntax paper had a constraint that is missing from the edits paper, viz that the generic-name in the procedure-stmt is only for a generic interface block that does not create a generic name (i.e. operator or defined assignment/input/output). Fixed by rewriting C1504 to add this requirement. [335:6+] 15.4.3.2 Interface block, R1507 specific-procedure, DIFF "a generic separate module procedure name shall be defined" ->"a generic separate module procedure shall be defined". It's the procedure not the name that gets defined! [336:7] Same subclause, paragraph 4, after the second sentence which begins DIFF Uncapitalised the sentence continuation after the first code block. [337:1] At the end of the subclause, after NOTE 2 and immediately before EXTRA Added missing constraint against using generic-name in the list when the generic-spec is a generic-name. [337:7+] Same subclause, after para 2, insert new paragraph NOTE: Deleting sentence 2 also deleted the definition of the "PROCEDURE statement", breaking references elsewhere. [337:10-13] 15.4.3.4.1 Generic identifiers, p1, DIFF "is not a generic-name" -> "is a procedure-name", twice DIFF Changed "procedure-stmt" to "PROCEDURE statement (R12nn procedure-stmt)" and made that the definition of the PROCEDURE statement. DIFF "specific-interface" -> "specific-procedure", twice. Actually, "specific-procedure" is not all that good since it can be generic... nothing better immediately strikes me, though. [337:13+] Same subclause, After the butchered p1, insert new p2 and p3: DIFF In NOTE 1, insert "constructs" after "SELECT GENERIC TYPE". [366:18-] Immediately before 15.6.2.4 Instances of a subprogram, DIFF: Inserted comma between "not present" and "or present with the value". Parenthesised "if default integer has 32 bits". [496:16+] 16.10.2 The ISO_FORTRAN_ENV intrinsic module, Done with rather a lot of changes. 26-110 US25 edits DIFF This was already done differently by another feature, but the definition was p8 in the next subclause, and included a requirement. Moved the definition part of that here, leaving the requirement behind. Defined this as double-barrelled {rank-remapping}{pointer assignment}, and did the similar {data}{pointer assignment} and {procedure}{pointer assignment}. Having the definitions here will allow future simplification (I did a little bit already). [193:9+] 10.2.2.2 Syntax of the pointer assignment statement, DIFF Rewrote to improve readability. [193:12] 10.2.2.2 Syntax of the pointer assignment statement, DIFF "of rank one" -> "of rank less than two", because another feature permitted rank-remapping of scalars. DIFF Rewrote moving the "in a" condition to the front, to improve readability and unambiguity. [193:23+] Same subclause, before DIFF "If a data pointer assignment statement is not rank-remapping," [193:24] Same subclause, C1022, COMMENT: These edits needed to be merged with the result of allowing rank-remapping pointer assignment for assumed-rank. DIFF Rewrote to start "In a rank-remapping pointer assignment..." [195:15] 10.2.2.3 Data pointer assignment, paragraph 8, COMMENT The final paragraph here (p12) would probably benefit by starting "If a data pointer assignment statement is not rank-remapping," [196:bottom-1] Insert at the end of NOTE 2: Done with more changes than expected. 25-203r1 US05: Edits for C interchange and extended floating types 26-112 update C std refs to latest revision (these papers interact enough that I had to merge the edits anyway). COMPLAINT The edits were not in order. Please try to have the edits in page and line order in future. Also, I note that not giving the subclause number and title increases the workload of the editor. DIFF Used our standard wording viz "the intrinsic module ISO_C_BINDING". "to allow" is not very good, it wasn't forbidden before. "to facilitate" is okay, or even just "for"... I chose the simple "for". DIFF I listed the named constants that were added. That will be useful when it gets moved into the Feature History (and is useful for implementers now). Except that I did not list the utterly pointless *_COMPLEX constants, as I think that adding them is a mistake. Also mentioned CFI_type_t codes. COMMENT Hard-coded this particular C standard reference only, so that it won't change the next time the C standard is revised. Again, I am thinking of the Feature History in the next revision. [xv] Add to "Intrinsic modules" the sentences: REJECT I did not do this. Please never tell the editor to replace a paragraph with a wall of text - there is a reason we say what the changes are, it is (a) easier for EVERYONE to find out what has changed, and (b) avoids losing existing typesetting and hyperlinking. COMMENT: BTW, it is a lot easier if you say what the paragraph begins with. TECHNICAL Why add the useless and redundant *_COMPLEX named constants? It just promulgates the confusion some people have thinking COMPLEX kind numbers are not merely the same as the REAL kind numbers for their parts. UTI 003 added for that. TECHNICAL Why insert a requirement of the C standard into our document? It is either contradictory (if the companion processor does not obey) or redundant (if it does). UTI 004 added for that. [539:7-14] Replace 18.2.2 paragraph 4 with the following paragraphs: COMMENT: The first three entries for COMPLEX should be "C_FLOAT or C_FLOAT_COMPLEX" "C_DOUBLE or C_DOUBLE_COMPLEX" "C_LONG_DOUBLE or C_LONG_DOUBLE_COMPLEX" and IMO, the rest should be shorn of their "_COMPLEX" suffix. [547-548:table 18.2] Add the following rows to the COMPLEX section of DIFF I only changed the C type, I did not insert a redundant synonym. UTI 005 added for that. [557:table 18.4] Replace the following: NOTE Replaced the C std ref throughout as it is a macro. Did not check result, [2:6] Replace the line: EXTRA I fixed the NOTE so that it is no longer false. I don't think that requiring processors to be able to interoperate with all C enum types is unreasonable - that's what we were doing before. Deferring this to a future revision would be straining at swallowing a gnat but not blinking at swallowing several camels. REJECT Instead, deleted this second reference to 6.7.3.3. [103:note 2] Replace REJECT This turns normative text into non-normative text. I do not think that that is appropriate. Instead, just fixed the reference in the normative text and did not change the explanatory NOTE which was perfectly ok. [551:16-17] Delete Done with rather a lot of changes. 25-201r1 "US09 Allow I/O of enumeration type names" DIFF "I/O list" -> "input/output list" (style - we never say i/o, always input/output). "namelist-directed" -> "namelist" (there is no "directed" there). first "input/output" -> "data transfer" "formatted input/output statements" -> "data transfer statements with a format specification" (because formatted === not unformatted, that is not what is intended). [xv] Introduction p2, Add under the Input/Output bullet: DIFF That makes the sentence about enumeration type identical to the one for enum type, so deleted the sentence about enumeration type and inserted "and enumeration type" before "data" in the enum type sentence. [300:19] 13.7.2.1p1 Data edit descriptors > Numeric editing > General rules DIFF Inserted space before E in Gw.dEe (first sentence). "character string" -> "standard form of the input field", "input list item" -> "effective item" TECHNICAL CHANGE permitted leading blanks! Actually so many changes needed I rewrote p1 from scratch, following the example of other edit descriptors. "output list value" -> "value of the effective item", "uppercase" -> "upper case", "enumerator-name" -> "enumerator name" etc etc etc p2 self-contradictory w.r.t. asterisks. Completely rewrote into the style of other edit descriptors, removing contradictions. [310:31+] After 13.7.5.3 "Generalized logical editing", a new subclause: EXTRA While checking this, I noticed that p2 about the r*c form, does not work for enumeration type input even though the paper added r*c output for enumeration type and r*c input form for enumeration type in namelist input. Inserted what I think it should be. COMMENT In this paragraph, "there is a nonblank character immediately after r*" seems moot, as blanks are not permitted in the r*c form except as permitted within c, and an undelimited character value cannot start with a blank, so r*[blank] is the r* form not the r*c form. ACTION PLEASE: Subgroup should confirm that this is what they intended. COMMENT: "A suitable value of w" is rather non-specific. But I guess no worse than for integer input. [316:15+] 13.10.3.1p6+ List-directed input forms COMMENT Reads a little oddly to have "enumerator name" followed by ", optionally signed", but it's not wrong. EXTRA Same paragraph, second sentence "The constant c" -> "If c is a literal constant, it". (enumeration types have no kind type parameter) [321:7] 13.11.3.3p1 Namelist input values ACTION FOR SUBGROUP: I looked at namelist output, and 13.11.4.1 has what looks like a mistake - it seems to permit values to be separated by a comma even when the decimal edit mode is COMMA, which would be ambiguous. I think that 13.11.2 effectively forbids that, but it would be better if 13.11.4.1 were not misleading. I suggest inserting "if the decimal edit mode is POINT" after the word "comma". Done with changes. 26-106 US14 Scoped enumerator access DIFF "enum-type-name" -> "enum type name" (there is no syntax rule, so just use plain text) [xv] Introduction, Data declaration bullet, insert sentences COMMENT: Mostly (152 vs 43) we have "[, something" not "[ , something". All but one of the cases in clause 7 use the minority form. Not changed, but maybe we should think about making these consistent? DIFF In C923b inserted "in a scoped-enumerator-value" after "enumerator-name". "enumeration-def" -> "enumeration-type-def". [150:9-] 9.4 Scalars, just before 9.5 Arrays, insert new subclause ACTION FOR THE EDITOR: I made proper "fake terms" for enum type and enumeration type, linking to their subclauses; go through the document later and change all the occurrences to use these so that they link to the definitions everywhere. Done with changes. 26-107r1 US08 Polymorphic PURE function results, edits COMMENT Actually hyperlinked PURE/SIMPLE attribute for types to type-attr-spec. [30:4+] 3 Terms and definitions, after 3.144.10 parent type, DIFF typo fix "SIMPLE type-attr-spec" -> "SIMPLE \si{type-attr-spec}". wordsmith "of a pure type, or a potential subobject component thereof" -> "of a pure type, or of a potential subobject component of a pure type" (one could work it out before as we're talking defined assignment, but it did not parse so easily). Corresponding change for the simple type constraint. [81:22-] Immediately before 7.5.2.3 Sequence type, insert new subclause at NOTE Used vertical ellipses instead of horizontal ones. [373:1-] Same subclause, after NOTE 5, viz immediately before 15.8, insert TECHNICAL CHANGE After "If the function result of a simple function has a polymorphic potential subobject component," changed "the declared type of the function result shall be simple" -> "the component shall have a declared type that is simple". This should be sufficient (and safe), and is parallel to the wording for pure procedures as well as for INTENT(OUT) args of simple procedures. (I think this was an oversight in the paper.) [373:14+] 15.8 Simple procedures, immediately before the first constraint Done with changes. 26-103r3 US20: Edits for Local Prefix Operation Intrinsics DIFF Used alternative style for these as the argument list is too long to fit with our usual style. EXTRA Re-typeset REDUCE itself to improve readability. [385] In 16.7 Standard generic intrinsic procedures, Table 16.1, DIFF Alternative style for heading as otherwise it doesn't fit. UNACCEPTABLE The wording "of the sequence defined by elements of ARRAY in array element order, with the result sequence provided in array element order" is overly complicated, and also, "result sequence provided" is just wrong. There is no result sequence provided. DIFF "DIM = DIM" -> "DIM", and "ORDERED = ORDERED" -> ORDERED. There is no need for keywords here. DIFF complete rewrite of semantics, no technical change. [469:21+] In 16.9 Specifications of the standard intrinsic procedures, DIFF Rewrote the result values to improve comprehension. Sorry, the MERGE invocations were invalid (only worked for default integer), otherwise I would have used them. I think my version is just slightly more readable than a corrected MERGE which would need three versions, e.g. MERGE(ARRAY,REAL(0,KIND(ARRAY)),MASK). [482:26+] In 16.9 Specifications of the standard intrinsic procedures, DIFF "The"->"the", "and"->", and", "."->", and OPERATION is not computationally associative;" COMMENT: Surely SUM and SUM_PREFIX_* are also processor dependent for floating-point? That should be noted in normative text and Annex A. [596:41+] In Annex A.2 Processor dependencies, insert the following line: Done with many changes. 25-204r3 "Consolidated edits for Templates" DIFF This sounds like an advertisement. That is inappropriate language for a standard. Not only that, but our generic subprograms also provide type-safe generic programming. As do generic type-bound procedures. The list is not quite endless, but it is long. Changed to the neutral "Templates, requirements, and instantiation". >tt Type-safe generic programming with templates DIFF (throughout) lots of confusion between syntax and semantics. A subprogram is syntax that defines a procedure. A procedure is an abstract thingo that does computation. There is such a thing as a "templated subprogram", but I have yet to see a "templated procedure", as the effect of a "templated subprogram" is to define a template that defines a single procedure. DIFF inserted term reference numbers for references to other terms. REJECT your own subclause calls it "instantiation association" not "deferred argument association" THEREFORE inserted a term "instantiation association". COMMENT I am not convinced that this is needed here at all. It is hardly ever used. Terms and definitions are for terms used throughout the document not something used in two places only. COMMENT I am not convinced that the subclause referenced is the best one [5:5+] Insert new glossary term: REJECT I do not see the need for "deferred constant" as a defined term. Better to hyperlink/cross-ref it to the subclause defining it. (We do not have terms for deferred type or deferred procedure.) [10:9+] Insert new glossary term DIFF inserted after default-initialized, not before. there is no such thing as a deferred-arg-list, it is deferred-arg-name-list they are not described in "Syntax for the TEMPLATE construct", they have their own subclause "Deferred arguments". ended the sentence in the NOTE with a full stop. [11:32+] Insert new glossary terms COMMENT: This makes me wonder if we should not gather all our "argument" terms together instead of scattering them. [17:18+] Insert new glossary term UTI 006 "same" looks wrong. [23:29+] Insert new glossary term UTI 007 this looks wrong too. [23:29+] Insert new glossary term DIFF uppercased the keywords for the constructs [24:3] 3.120 scoping unit: Change "or subprogram" to "subprogram, DIFF I shortened the BNF for the templated subprograms so the BNF rules typeset better. [27:12] 3.139 subprogram: Change "or subroutine-subprogram (R1537)" to REJECT This is only used twice, and appears to be wrong - unless requirements cannot be accessed by use association, which would be surprising. [32:16+] Insert new glossary term DIFF renamed BNF "template" to "template-construct" since the text talks about template constructs. Similarly requirement-construct. DIFF inserted alphabetically as that is how it is ordered COMMENT If you want to change these to template-definition and requirement-definition those would also work. But if you want to keep them as constructs, then in prose the keywords must be uppercase. [44:20-28] In 5.1 High level syntax, extend R508 DIFF inserted alphabetically, sigh. [44:37-38] Extend R512 to include templated procedures such that it REJECT a TEMPLATE is not a program unit or subprogram. note that we have ordering requirements for BLOCK constructs, derived-type definitions, etc., and these do not appear in this table for the same reason. [48:1+] Update first line in table 5.1, to include TEMPLATE such that REJECT This is not adequately motivated. I did abbreviate "Statement function" to make that column narrower. [48:9+] In Table 5.2, delete the row for "statement function". REJECT Instead, I put External/Module/Internal subprograms as subdivisions of a higher-level "Subprogram" heading, that reduced the width of those columns significantly, enough to keep Block Data. [48:9+] In Table 5.2, delete the column for "Block data", along with DIFF Recorded that statement functions are not permitted in templates. [48:9+] Add a new column to Table 5.2 Statements allowed in scoping units, REJECT You said you added templated subprogram to the syntax of module subprogram and internal subprogram, and if that is true, they are not separate things. [49:2] 5.3.3 The END statement: After "module subprogram", insert ", REJECT A REQUIREMENT construct is not a subprogram. Nor is a TEMPLATE construct. They are nonexecutable by virtue of being in the class . THEY ARE NOT PROGRAM UNIT OR SUBPROGRAM END STATEMENTS. [49:7] After "end-module-statement", insert ", end-template-statement, REJECT This is not a new kind of type. [51:27+] After 5.4.1.3 Derived type, add a new subclause: COMMENT Did I say how much I dislike braces? And it makes typesetting with LaTeX tedious. EDITOR FUTURE ACTION: try something different for the brackets, these are in maths font which looks a bit weird now. [62:4] 6.2.6 Delimiters FAIL "deferred-type" is an undefined BNF term. DIFF I made a new term deferred-type-name and used that. Added to the end. [68:16-19] In section 7.3.2.1 Type specifier syntax, insert DIFF deferred-type-name, also instructions were incomplete. [68:20] In C703, after derived-type-spec, insert 'or deferred-type' DIFF deferred-type-name. At the end of the TYPE and CLASS things. [68:21-30] In R703 insert '<> TYPE ( DIFF Rewrote this and surrounding constraints instead. No, they are not all in the same style. [68:31] Change C705 wording to be consistent with constraints just DIFF Merged into C705 instead. [68:34+] After C705, insert a new constraint: DIFF Rewrote C706 instead. [69:1+] After C706 introduce a new constraint DIFF Rewrote C737 instead. [80:27+] In 7.5.2.1 Syntax of a derived-type definition, insert a new DIFF uppercased template. [113:15] In 8.5.2 Accessibility attribute, in C817, insert "or REJECT No need. Instead, added a new "implied-rank-spec" and a constraint permitting it only in deferred constant declaration statement. [118:14] In 8.5.8.1 General, change the last entry for REJECT absolutely no need [118:19] Modify R818 to disambiguate lower and upper explicit bounds REJECT nope. [118:21+] After R818, insert new rules: COMMENT I dislike the currently-common case being downgraded to "otherwise", but I did it anyway. [121:21] In 8.5.8.6 Implied-shape array, change "the constant-expr in DIFF Reworded and put into the first sentence. [121:21] After first sentence, insert new sentence: REJECT I refuse to make the extent unspecified. Instead, changed constant-expr to constant expression. EXTRA Changed "1" to "one". [121:27-29] Delete the first sentence of p3 starting with "The extent REJECT entire set of changes to 8.5.8.7 which are pointless and unnecessarily confusing. Instead, introduced BNF for implied-rank-spec. [121:30] Change name of section 8.5.8.7 from "Assumed-rank entity" to DIFF Used new BNF for implied-rank-spec. COMMENT Not entirely convinced you really needed to borrow that syntax. DIFF Example was blatantly invalid b not a deferred arg, cannot appear in DEFERRED whatever. c is a deferred arg, cannot appear in a normal type declaration, d not a deferred arg, but no value in its type declaration stmt. n is a deferred arg, but not declared as anything I replaced the whole example with a significantly different example. TECHNICAL CHANGE You say an implied-rank thingo cannot be a named constant other than a deferred constant, but as I could see no reason for that to be necessary, I deleted that requirement. Please advise if there is a good reason. [122:8+] Insert new section INCONSISTENT editing instructions. Tried to fix. EXTRA Added text to the Implied-shape array subclause to mention this as a possibility. Added your new general feature to the Introduction. [127:3] In 8.5.17 RANK clause, in C864, replace "a dummy data object DIFF reworded. [128:36-37] In 8.6.1 Accessibility Statement, in constraint C873, after DIFF reworded as constructs. [129:1-2] In constraint, C874, replace "or namelist group" with DIFF reworded [129:2+] Introduce new constraint: DIFF TEMPLATE construct. Second one "module"->"scoping unit" instead. [129:7] In second sentence of p1, insert "or template" after "in the DIFF TEMPLATE construct [129:9] In last sentence of paragraph 1, insert "or template" after DIFF TEMPLATE construct [129:16] In first sentence of paragraph 2, insert "or template" after "in DIFF TEMPLATE construct COMMENT seems unnecessary but harmless. [129:19+] Introduce a new paragraph after paragraph 2. DIFF reworded DIFF An internal/module subprogram can be templated, so I needed to insert some ugly words. [136:30-32] In 8.7 IMPLICIT Statement, replace the last sentence of COMMENT Why does this not apply to non-deferred interface bodies inside TEMPLATE constructs? WRONG "or an..." should be an "and" condition. UTI 030 Inconsistent interface treatment re implicit mapping and importation. [139:7] In section 8.8 IMPORT Statement, in second sentence of p2, DIFF different [139:14] In sentence+ 2 of p4, replace "or submodule" with "submodule, REJECT "possibly not necessary" -> instead, I made it clearer that a deferred constant is a named constant by adding a sentence to the subclause that defines them. [187:4] In, 10.1.12 Constant expression remove " or" from end of item DIFF "deferred-type-name". [225:17+] In section 11.1.11.1 Purpose and form of the SELECT TYPE DIFF Reworded to omit the syntax rule number. EXTRA Reworded existing constraints to omit the syntax rule number. [226:9+] Add new constraint on R1156 type-guard-statement: DIFF The templated BNF name was shortened. [326:12+] In 14.2.1 Module syntax and semantics, add the following DIFF "TEMPLATE constructs, and templated subprograms". I might have let the former go, but a templated subprogram "defines a template" so is either a template or a templated subprogram. [327:2] In section 14.2.2 The USE statement and use association, DIFF I don't think we need to always call out the case of templated subprogram as it defines a template, no? Oh, and there is no such thing as a templated procedure - it is a templated subprogram. WRONG I think that procedures that are private to a template also have explicit interfaces, therefore "accessed from the instantiation" -> "defined by the instantiation". Inserted cross-reference to the Instantiation subclause. EXTRA split the last item in two, as the previous text only worked as a single item when it was the last. [333:24] Replace ", or" with "," at end of 2nd bullet. DIFF "scoping unit containing the interface-body". [335:23+] Introduce new constraint on rule 1503 interface-stmt: DIFF: Combined the next two edits and reworded. [336:2] In last sentence of p2, replace "with neither Abstract nor" DIFF put into p2 where it belongs with the other "introduced by". [336:3+] Insert a new paragraph: DIFF "deferred attribute" is not defined. You use "deferred kind" as if there were only one kind type parameter. Added definitions of "deferred kind type parameter", "deferred rank", and "deferred attribute" to be one of those. DIFF omitted ", or in default kind declaration" as I do not know what you are trying to say. DIFF There is no RANKOF clause - replaced with RANK(RANK(blah)). COMPLAINT You talk about deferred rank, then suddenly in the example it is all "implied rank". UTI: 028 on the apparently-incomplete definition of deferred rank (and like deferred type). 029 on the nonsense example. [340:8+] In 15.4.3.4.5 Restrictions on generic declarations, insert 4 COMPLAINT Too often this paper has undefined BNF terms. More care is needed. REJECT As a deferred procedure is a procedure, this seems to be covered by procedure-name already. [344:19+] In section 15.5.1 Syntax of a procedure reference, append REJECT Covered by procedure-name. [355:5+] Extend R1524 with and DIFF Reworded. COMMENT Actually, we could say "templated FUNCTION or templated SUBROUTINE statement", if you think it would read better. (I'm fine with the BNF.) [363:33+] Insert new constraint on R1530: COMMENT You could have made end-templated-function-stmt instead of adding a messy constraint. DIFF Reworded. [365:11] In section 15.6.2.2 Function subprogram, in C1573, after "in DIFF Reworded. And did not introduce a spurious rule reference. [366:15] In section 15.6.2.3 Subroutine subprogram, in C1576, after DIFF I don't think "a" is needed. Also inserted into CO_REDUCE_PREFIX_* [410:24] After second sentence in Arguments paragraph, insert a new DIFF You called this "instantiation association" in the defining place. EXTRA Added "instantiation association" to the definition of "name association" in clause 3, to the list in 19.5.1.1 (now 20.5.1.1), and also to the list of mechanisms by which entities known in one scope may be accessed in another scope. EXTRA "may" -> "can" there. DIFF Added to the end of 19.5.1, inserted witter explaining what it is about (but without any details). [576:17+] Insert new subclause: COMMENT Did you really not notice that these are all ordered by the subclause number where they are described? REJECT This is not where it goes. [597:43] Replace final period "." with semicolon ";". DIFF Inserted into the correct place. Reworded. [597:43+] Append a new bullet in the list of processor dependencies [Here are the comments on the new clause] DIFF "template-declaration-construct" -> "template-declaration". (too long). DIFF "template-specification-construct" -> "template-specification" (ditto). DIFF "templated-function-subprogram" -> "templated-func-subprogram". DIFF (templated-function-stmt) "dummy-arg-list" -> "dummy-arg-name-list". DIFF (constraint requiring TEMPLATE prefix-spec) reworded, repositioned. DIFF "templated-subprogram-specification-part" -> "templated-subp-specification-part" (too long). DIFF "templated-subprogram-declaration-construct" -> "templated-subprogram-declaration". too long. DIFF "deferred-const-declaration-stmt" -> "deferred-const-decl-stmt". DIFF "deferred-proc-declaration-stmt" -> "deferred-proc-decl-stmt". DIFF paper used the undefined BNF "". Changed to "interface-name". DIFF "may" -> "can"; you cannot give permission in a NOTE. DIFF "templated-procedure-instantiate-stmt"->"templated-subp-instantiate-stmt" (it is still long, maybe can we have a shorter word than "templated"?) "template-name" -> "templated-subp-name". COMMENT (NOTE in templated inline instantiation): This is stating the obvious! DIFF (template dependence) Rewrote because it was wrong: local names are local identifiers of local entities. The phrasing is "accessed" - the local entity is accessed by use association, etc. Also, as worded it left the door open to dependency via defined/overloaded operators. COMMENT Do we *really* want to allow inline-instantiation in specification expressions? Ugly. DIFF (interpretation of template expansion) I rewrote this as it needed restructuring and was confusing. Constants have the same type always, it's right there in the template. (I think CHARACTER is assumed, though, so length type parameters might differ. Also, "are equal" doesn't work with IEEE signed zeros. DIFF (instantiation args) Reworded to be more explicit, improve typesetting. DIFF Introduced "instantiation procedure" to simplify discussion. DIFF (generic-spec instantiation) not "exactly one", because our disambiguity rules already force that. we just need to require that there is a match. DIFF rewording means we can state the requirements on that procedure, whether we got it via specific or generic. note that the way the paper worded the generic rules they didn't quite work anyway. DIFF note 1 (just before REQUIREMENT construct) just regurgitates the first constraint on procedure-name. Omitted. COMMENT (in remaining note i.e. example) actually, I think the template and templated subprogram should be right here! Put a simpler example where they are now. COMMENT I do not understand why this restriction is desirable. (A \si{requirement-construct} shall only appear in the \si{specification-part} of a main program or module.) TECHNICAL CHANGE: (policy) the end-requirement-stmt is not allowed to look like a subprogram end statement, i.e. the REQUIREMENT keyword is not optional. DIFF: Omitted NOTE about deferred-arg-name being local to the construct. We don't say that in any of the other obvious cases. DIFF deleted "A REQUIRE statement is a specification statement." we never say things like that! DIFF (Examples of REQUIREMENT and REQUIRE) I changed the names of the deferred arguments of R2 to make it less confusing to read. DIFF (consistency of deferred arg specs) changed level as it was an orphan viz tt.8.2 when there was no tt.8 let alone a tt.8.1 or tt.8.3. DIFF deleted "in a given scoping unit", since you can't give a deferred arg a direct specification anywhere other than in its scoping unit. Unless I am very much mistaken. DIFF (note before "Specification of deferred types") This was just restating the normative text in microscopically different words, so added nothing. Reworded to try to make it more informative. DIFF Omitted "A deferred argument has at least one ultimate specification." which is a trivial rewording of a normative sentence one paragraph ago. DIFF (Specification of deferred types) Added normative text to support the claims about validity in the examples. DIFF (note about instantiation arg to abstract deferred type) It's not just abstract deferred types that cannot be an instantiation argument to a non-abstract deferred type, but any abstract type. DIFF (specification of deferred constants, last para) reversed ordering, so that we don't need to put in a note that a scalar ultimate specification has explicit shape. DIFF For a procedure, PURE/SIMPLE/ELEMENTAL are not attributes, but keywords in the prefix that specify it to be pure/simple/elemental. DIFF Omitted NOTE about dummy names not being characteristics, because (a) everyone should know this (b) it is discussed in detail about a paragraph or two later. Done with so many changes. 26-109r2 US16 Default kinds COMMENT wrong editing instructions, it was p4. Line location was correct though. [72:10-11] Same subclause, p3, replace entire paragraph with COMMENT Should have noted this is 7.4.4.2. Line location was correct. [75:30-31] Move p2 to follow p3, and change EXTRA same para, "nondefault" -> "nonsystem", thrice. [75:32-76:2] 7.4.4.2 Character type specifier, p3, DIFF Minor wording tweaks. [138:1-] Immediately before 8.7 IMPLICIT statement, insert new subclause DIFF "of type nondefault character" -> "of nonsystem character kind". [311:19,20] 13.8.1.1 Position editing, p1, NOTE I did the suggested factoring to improve typesetting. [327:12-13] 14.2.2 The USE statement and use association, R1409 use-stmt, DIFF typo "DEFAULT_KINDS_clause"->"DEFAULT_KINDS clause". [328:7+] After p3 "A use-stmt without a module-nature", insert new paragraph NOTE hyperlinked all of these including the unchanged double precision ones. [386:12+ to 387:end] 16.8 Specific names for standard intrinsic functions, EXTRA: also for ERRMSG in CO_REDUCE_PREFIX_* [411:6] 16.9.57 CO_REDUCE, p3 Arguments, ERRMSG argument, EXTRA: also for ERRMSG in CO_SUM_PREFIX_* [411:38] 16.9.58 CO_SUM, p3 Arguments, ERRMSG argument, DIFF typo in edit instructions CMDSTAT actually CMDMSG [422:28,423:7] 16.9.83 EXECUTE_COMMAND_LINE, p3 Arguments, EXTRA later in that argument, "number N of integers" -> "number N of standard integers". [466:16] 16.9.169 RANDOM_SEED, p3 Arguments, SIZE argument, DIFF p3 "shall be default character scalar" -> "shall be a default character scalar". [472:26,29] 16.9.180 SELECTED_CHAR_KIND EXTRA throughout [16.10.2 The ISO_FORTRAN_ENV intrinsic module] "default integer" -> "standard integer" (kinds of the named constants) and "Default integer" -> "Standard integer" (result of MAX_RANK). and "HUGE(0)" -> "HUGE(0_STANDARD_INTEGER)" ditto {That is the kinds of the named constants.} [493:17-] Immediately before 16.10.2.9 ERROR_UNIT, insert new subclause COMMENT Did not do a completely thorough check, the ones I did look at looked ok. [508-570] Clause 17 Exceptions and IEEE arithmetic, and clause 18 ok + [522:26] 17.11.34 IEEE_REAL, p5 Result Characteristics, change "default real" to "single precision real". {All the other uses of the term "default real" in these clauses are correct.} EXTRA noticed some typesetting glitches in "Association of storage sequences", tweaked. DIFF: Indexed "standard integer" et al where I thought the text was relevant to the kind itself. Done with changes. ===END===