J3/14-239 To: J3 From: Malcolm Cohen Subject: Editor's report for 14-007r2 Date: 2014 October 01 1. Introduction This is the editor's report for applying the papers passed at meeting 204 to the draft revision. Comments are in order of application of the papers, which does not quite match either the passing order nor numerical order. Extra edits applied are marked EXTRA if they are significant. Items for possible action are marked "ACTION"; action will be taken at meeting 205 by /EDIT subgroup in collaboration with other relevant subgroups. 2. Report Updated title and page header to 14-007r2. 14-186. Removed from Makefiles as well as from the document. 14-187r1. [26:19+] should have been [6:19+]. [64:9-11] Also hyperlinked LOCK_TYPE to c13. [84:21] R469 should have been R459. [205:3] et al; also changed indexing of I/O rounding mode. [510:28-53] Additional changes "END or ERR" -> "end-of-file or error", "any end or error conditions" -> "any end-of-file or error condition", "There" -> "there" (instead of deleting it). [511:9-1] Additional "END/ERR" -> "end-of-file and error". ACTION: I wonder if "pending communication affector" and "pending input/output storage sequence affector" should be indexed. (These occur in c05, c09, c15 and maybe c16.) 188r1. [35:37][35:37+][36:0+6-9] are all 2.3.6 not 2.3.4. [57:0+16] Also "the SIGN function" -> "the intrinsic function SIGN", hyperlinked. EXTRA: [58:0+6] "is required to be a scalar and is not permitted to be a pointer, allocatable, or a coarray" ->"cannot be an array, an allocatable object, a coarray, or a pointer". {Similarly prohibited language specifying requirements!} END EXTRA [104:10+12] Also singularised the dependent clause, i.e. "because pointers" -> "because a pointer", "entities" -> "an entity". [105:16+1-4] At least one member of the committee agreed with my suggestion that after normatising the active text, the remnants were not noteworthy, and reviewing it I have to agree, so I just inserted the new normative text and deleted (the rest of) NOTE 5.25. ACTION: If you want what was left of NOTE 5.25 reinstated, please ask. [144:5+more,145:0+5] Also "may be used by the processor" ->"can be used by the processor". EXTRA: Before [237:11+5], the note contained the statement "However, the value returned shall be suitable for use as the value of the \si{file-name-expr} in the FILE= specifier in an OPEN statement." This is stated as a requirement. We cannot do that in a note. I assumed that we actually did want this requirement, so I moved it to the preceding normative paragraph, appending it whilst changing "However, the" to "The" and "returned" to "assigned". END EXTRA [292:0+7-8] Entered as specified, but the paragraph still seems a bit hard to read. Perhaps this should be more substantially rewritten? ACTION: Review for possible further wordsmithing. [293:14+12] additional edit "; if the interface is specified by an interface block, the name of the last argument shall be PRINT" ->", and if the interface is specified by an interface block, the name of the last argument is PRINT". [303:0+lots] additional "shall not be directly referenced" ->"cannot be directly referenced". [412:10+1-413:0+8] "this requirement" -> "those requirements". ALSO: Hyperlinked and indexed "C address" throughout c15 and c16. [443:22] Instead of "header"->"source file", "header file"->"source file". [509:34-510:2] Also deleted NOTE 9.25 on page 211. [515:2 etc] "Access to some of these may be made" ->"Access to some of these can be made". EXTRA: [292:0+7] NOTE 12.21, p1, After "be invoked from outside of the", changed "host procedure scoping unit" -> "host subprogram" because it is common to be invoked from outside the host scoping unit, it is outside the host subprogram that is new. (And there is no such thing as a "host procedure scoping unit"). END EXTRA [525:25-27] p1 is still broken, for example "because their definitions are not in a Fortran program unit" is not a reason for being considered "external", seeing as how external subprograms *are* program units and define external procedures anyway! Also p1 still contains impermissible wording. ACTION: Rewrite p1. [elsewhere in ac] Examples are wrongly typeset e.g. with para nums. ACTION: Review example code typesetting in Annex C, correct paragraph numbers that I did not fix this time, make all inline examples indented - none of those should be flush left - probably best to indent everything the same amount. [526:1-3] Also indented example code by 7 spaces. [531:20-21] Also "generic procedures names" -> "generic procedure names". [535:6,10-37] Omitted edits as a later paper will delete this anyway. [555:4,9-10] Also reworded second sentence to avoid "is permitted". [556:2,4,6,9,10] changed new text: ", for example:" -> ". For example,", before "which contains the integers" inserted "is a rank-one array". 174r1. [xviii] "logical unit" -> "unit" (no such thing as a "logical unit"). 176r2. [xviii] "In a \si(data edit descriptor), the exponent width \si(e) may be zero." ->"The exponent width \si{e} in a data edit descriptor can be zero, analogous to a field width of zero." since the BNF is data-edit-desc, not stating the effect is not so useful, and it's better to use "can". Hyperlinked "data edit descriptor" to the BNF data-edit-desc. [253:14] Rewrote since this text was changed by another paper already. [253:25+6] Put a horizontal line in between Ee and E0 forms, instead of a new footnote (2), appended to footnote (1) with "and", instead of "represent the exponent" used "represent the value". ... ditto for the other tables. [254:27] Rewrote to use the correct "contains" terminology (the other paper missed this one). 177r1: [intro] While here, noticed some "is permitted" language... "SIZE= is permitted with" -> "SIZE= can be used with", "The intrinsic functions ... permit the ... to be" ->"In references to the intrinsic functions ..., the ... can be", "ERROR STOP is permitted to" -> "ERROR STOP can". [281:8] Also swapped C1207 and C1208 (since C1208 is a constraint and precedes ). Hyperlinked "GENERIC statement" to the new GENERIC statement rather than the type-bound GENERIC statement (which remains a definition). There were no hyper-references to the type-bound GENERIC statement anyway. 178r1: Done without modification. 139r3: [315:1-2 C1296(6)] Also deleted following "or", otherwise it said "corresponding to a dummy argument or with the POINTER attribute". Also: a few lines earlier, hyperlinked "intrinsic assignment statement". [478:12 16.6.7p1(12)] Insert of Append ", unless both the dummy argument and the actual argument are pointers" at the end of the item, did insert "is not a pointer and" before "has" (If the dummy is a pointer with INTENT(OUT)/INTENT(INOUT), the actual argument is ipso facto required to be a pointer already, so we don't need "both" here.) [478:26-27 16.6.8p1, fourth list item] Omitted as it was already done by 14-187r1. 202: [Intro] Did a completely different insertion. [55:17] Inserted at 14+ instead, where it belongs. EXTRA: [174:31] deleted C815, because I had to retypeset R819 so had to read it carefully, and got annoyed by "scalar-mask-expr" which is already constrained to be scalar and of logical type, to be additionally constrained to be scalar and of logical type. [174:27 et al] Renamed "concurrent-triplet-spec" -> "concurrent-triplet", to make it typeset better. It is still not an ideal BNF name (it not being a "spec" or a "triplet"!!!). Perhaps we can merge these proliferating loop-controls? If not, "concurrent-control" might be better. END EXTRA ACTION: Review this BNF for possible simplification or renaming. [462:26 16.4p4] ", it is of type integer as specified in 4.4.2.2" ->"it has the specified type and type parameters" i.e. exactly the same words as DO CONCURRENT and FORALL. EXTRA: [463:4] inserted comma after first "construct" on this line. END EXTRA 168r4: [xviii] Wordsmithed. [throughout] "integer type" -> "type integer". [342:33 and many others] "minimum decimal exponent range of" ->"decimal exponent range of at least" EXTRA: [throughout c13] Changed en dash to minus sign (it was always being used to mean minus). END EXTRA [351:28] Instead, "a default integer" -> "an integer". [395:6] Ditto. [414:6] Instead "default" -> "of type". [414:19] Ditto. [415:22] Instead "default" -> "a". [421:4] Ditto. 175r3: Unfortunately this paper is completely inadequate, indeed its edits are neither necessary nor sufficient: - Edits are needed to c10, e.g. in "In the input field for the I edit descriptor, the character string shall be a signed-digit-string (R410), except for the interpretation of blanks." to change the requirement into error-condition-raising. - Edits are not needed to the definition of a formatted record. - Edits are not needed to the "Error conditions..." subclause either, and the edit supplied makes it wrong (we already had one standard-specified i/o error, which this edit implies does not exist). REJECTED. 172: This is a technical change without feature permission. (The technical issues here are, unless I am mistaken, being addressed by the interpretation process.) REJECTED. 200: Done without modification. 181r3: Added extra witter to the Result Value paragraph to improve typesetting. Tidied up the code in the example to look a bit more reasonable. 183r2: [xviii] "is provided to test" -> "tests". [elsewhere] "can ... without error" -> "cannot ... safely", so that the handwavy description matches what the function actually returns, rather than the converse. 204: [xviii] "KIND= is not needed to specify" -> "no keyword is needed for". [later] "The result ... is the complex value" ->"The result ... has the complex value". (A result has a value, it is not a value in itself.) 179r2: [xviii] "default. The" -> "default; the" (this is a consequence so better stated in the same sentence). Defined RECURSIVE and NON_RECURSIVE as keywords using the new LaTeX macros for Fortran keyword management; other prefix-specs are not so defined and this ought to be done sometime. ACTION: Check other keywords, in particular the prefix/suffix ones, and change all to the new keyword macros so they will be indexed and hyperlinked consistently. 203: EXTRA: [357:21+1-3] Deleted NOTE 13.14. [395:23+1-3] Deleted NOTE 13.26. END EXTRA 198r1: many places: "2"->"two" and "10"->"ten" for rigor. [247:19] Edit not done as this constraint was deleted by another paper. EXTRA: [251:9] 10.7.2.1p1, item (2), after "ES," insert "EX,". {Decimal symbol in the input field overrides "d" spec for EX on input when the input is *NOT* a hexadecimal-significand number.} [252:10] 10.7.2.3.2p2, after "IEEE exceptional specification" insert ", hexadecimal-significand number,". {Lowercase is equivalent to uppercase.} END EXTRA [252:12] Also deleted "either" before "an IEEE exceptional". {Grammar.} [255:12-] Added a witter paragraph introducing the EX edit descriptor. Deleted "for a scale factor of zero" since the scale factor is already stated to have no effect. Changed the examples since the internal value was meant to be the mathematical value, not Fortran syntax; added "with SS in effect" to the title of the third column. Also... NOTE: The description is ambiguous in that it does not state how to choose the exponent e.g. 1.P+0 vs. 2.P-1 vs. 4.P-2 vs. 8.P-3. The C standard explicitly states that this is unspecified (aka processor dependent), except that zero has an exponent of zero. (It does make the suggestion that the mantissa could be "nibble-aligned", but this is not even a recommendation.) Therefore I changed the third column heading to "Possible output with SS in effect" (and changed capitalisation of the other heading to match. ACTION: (1) We should require the exponent for zero to be zero. (2) We should explicitly state that the exponent shall be chosen so that the first hexadecimal shall be nonzero, but that there is no other constraint. (3) OR, we should decide on how to choose the exponent so that the output is completely portable. ACTION: The example tables in other edit descriptors have inconsistent capitalisation. I suggest "First word only capitalised". ACTION: We say "the form of the output field" (here and elsewhere) but do not say "without embedded blanks" (the form includes embedded blanks!). We should probably say it explicitly. Do we say somewhere that it can have leading blanks? I don't see it for e.g. EN editing. Also, we usually have blanks in between each syntax item in the form, except between the mantissa and exponent. The form for E and D has a blank between the optional sign and the optional leading zero, but nowhere else. We should change them all to have a blank in between each item. [255:12-] (continuing) The first example was wrong (it was formatted like EX0.1 not EX0.2 as it claimed); changed the edit descriptor to EX0.1. EXTRA: [405:20+lots] Rewrote the out of date footnote which used language inappropriate for an international standard ("we"). END EXTRA [406:12] I did this optional edit. [406:27+] Looking around here, I see that p2 needs editorial improvement: (1) it says is defines the following types, but one item is full of named constants; (2) the list format is defective; i.e. it should be a proper semi-colon separated list explaining the types plus another list explaining the constants. Or done completely differently. (3) it uses \mindexd*, but it should use \deftype* and all refs should use \reftype. (4) all the named constants should use the \defconst family (the new ones do); actually the \defconst should be in the definitional paragraph and the summary should be a link... ... all this needs better structuring! ACTION: Rewrite this subclause to structure it more effectively. [407:4] Added a comma after the insertion. EXTRA: [409:0+2] After "affected by the rounding", "mode"->"modes". END EXTRA [409:22] This edit was moot after [409:22-23]. ACTION: 14.10 Summary of the procedures, p4, states that the elemental functions are available for "all reals X and Y". This does not handle IEEE_QUIET_compare which has (A,B), nor IEEE_FMA which has (A,B,C). It also does not mention integers (IEEE_SCALE) or logicals or indeed subroutines (IEEE_GET_FLAG). Maybe, either delete the text (probably bad) or state that unless otherwise specified, arguments of intrinsic type are accepted regardless of their kind type parameter value? NO UTI BUT ... "14.5 Underflow mode" is now described wrongly; the IEEE standard includes an "abrupt underflow" mode ("alternate exception handling"). ACTION: Consider rewriting 14.5 to reference IEEE section 8.2. ACTION: Should "underflow mode" and "halting mode(s)" not be indexed? NO INTERP/UTI BUT ... "TYPE(IEEE_STATUS_TYPE)" is factually incorrect, the type is called "IEEE_STATUS_TYPE", the "TYPE()" stuff is just the syntax around *SOME* (not all) appearances of the type name! EXTRA: [c14] I changed some of these (not yet all). END EXTRA ACTION: Get rid of remaining extraneous "TYPE("...")" syntax in prose. EXTRA: [c14] - Changed some examples to have a space between the procedure name and the opening parenthesis, just like we do when we write function references in normative text, and hyperlinked the name to the function definition. - Used the deftype family on IEEE_ROUND_TYPE. - Changed some colons in examples to ellipses. END EXTRA ACTION: (1) Check other examples in c14 for inconsistent spacing. (2) Use \deftype macro family for all IEEE module types. (3) Change colons that should be ellipses to ellipses. NO INTERP/UTI BUT >>> 14.8 Exceptional values ... "inquiry functions ... are provided to determine whether these facilities are available": what facilities? Needs rewording, especially since we actually say what the inquiry functions mean twice already elsewhere (14.9 plus in the function desc). ACTION: Reword. DESPARATELY SEEKING WORDSMITH: The various functions are "provided to inquire whether the processor supports..." Why do we have this unnecessary and undesirable rationale here? Just say (1) what "support" means, and optionally (2) function IEEE_SUPPORT_XYZ "inquires" or "returns", don't try to say why we provided the function! ACTION: Remove unnecessary waffle, replace with requirements if needed, or with simple statements of fact if appropriate, or just delete if nothing is needed here anyway. (I think we generally want some statement of facts...) MISSING EDIT: 14.9p1 various bullets seem to be totally wrong. ACTION: Paragraph needs a complete rewrite. [413:26+] "representation mode" -> "representation method". [414:29+] "shall be scalar of type" -> "shall be a scalar of type". CHANGED EDIT: [414:32] "IEEE denormalized" -> "subnormal". (All other cases of this were not prefixed with "IEEE".) EXTRA: [414:33], [415:8] "shall be scalar of type" -> "shall be a scalar of type". END EXTRA CHANGED EDIT: [417:14+] After "if both X and Y are quiet NaNs the result is", changed "processor dependent"->"X or Y (processor dependent)", 4 times (each function in this insertion). EXTRA: [417:24] Changed "/=" to "$\ne$" i.e. a proper not-equals sign, since this is not Fortran but maths. END EXTRA [417:28+] I used the infinity symbol rather than the word "infinity", since we are talking about values. ACTION: If people think we should use the word not the symbol, this should be changed. If people like it we could consider using the symbol in other places. [417:28++] In IEEE_QUIET_NE, fix copy-paste-edit glitches: "compareQuietLess" -> "compareQuietNotEqual", and after that, second "false" -> "true", and in the example, "false" -> "true". [417:28+++] In IEEE_REAL, ", or if KIND is present and specifies a representation method for which IEEE_SUPPORT_DATATYPE would have the value false" ->", or if IEEE_SUPPORT_DATATYPE (IEEE_REAL (A, KIND)) has the value false". (just in case default real is not an IEEE kind). [420:3-] "shall be scalar of type" -> "shall be a scalar of type". EXTRA: [421:27] "denormalized" -> "subnormal" (I don't know how I missed this before.) [425:19+] and [422:6+1-6] Replace NOTE 14.13 in IEEE_SUPPORT_DENORMAL with a new note "A reference to IEEE_SUPPORT_DENORMAL will have the same result value as a reference to IEEE_SUPPORT_SUBNORMAL with the same argument list." The copy of NOTE 14.13 in the new IEEE_SUPPORT_SUBNORMAL subclause has the original-as-revised contents. END EXTRA ACTION: We variously say "shall be a scalar of type blah", "shall be a blah scalar", "shall be scalar and of type blah". for intrinsic blah, we should always use the second formulation; for derived blah, we should always use the first formulation. 135r6: Done without modification. 184r4: [324] Added definite article and full stop. [325:4] Deleted "one of" (what if more than one of?). [381:18+] "seed value" -> "seed", twice. "processor-dependent seed value set is not dependent" ->"value to which the seed is set does not depend", "code" -> "statement". I note that IMAGE_DISTINCT=.TRUE. requires the image index (or something equivalent that necessarily differs from one image to another) whilst IMAGE_DISTINCT=.FALSE. also forbids things that merely *might* differ from one image to the next from being used as a source of entropy - which means that nearly ALL sources of entropy are forbidden as nearly all of them might differ between images (e.g. process id, process startup time, network address, data from /dev/random, etc. etc. etc.). This might cause difficulties for REPEATABLE=.FALSE. IMAGE_DISTINCT=.FALSE. as that could apparently require a global-across-all-images "nonce" to be maintained. Still, the user's only going to call this once, right? ACTION: Perhaps some more thought is required. UTI 010 discussion: Unfortunately the claim in the example is not only completely at odds with the fact that the RNG is permitted to be a common generator, but makes a statement that is not in any case supported by the preceding text. To be honest I think this means we might want to redesign RANDOM_INIT, or at least verify that it is usable to do what the UK requirement actually wants (which was in fact satisfiable with a common generator). Therefore rather than unilaterally rewriting the claim in the example to be consistent with the normative test, I added UTI 010. 191r3: I note that in the edit for [xviii], "end statement" ought to have been "terminating statement", since these are not "end statements" in the normal meaning of the term in the standard. [25:10+] These incompatibilities are unauthorised technical changes. [46:25-26] This edit makes the sentence into nonsense - the enddo or continue statement is not part of the block (though it was part of the range). REJECTED. It would appear that the incompatibilities (additional restrictions) being suggested are mere oversights (mistakes) in F2008, so it would seem that the interpretation process should be used to correct these. ACTION: Raise an interp request for the apparent defects. 194r1: [all] hyperlinked "intrinsic assignment" to "Intrinsic assignment statement", and indexed as "intrinsic assignment statement". NOTE: We always index as "intrinsic assignment statement" (and thus, as "statement!intrinsic assignment" as well), there is no index entry for "intrinsic assignment" other than the statement. NOTE2: If we want to differentiate between "intrinsic assignment" the concept vs. the statement ***in the index***, then all the refs in the index will need to be checked to see which of them should be the concept. It seems easier just to leave as is though (i.e. I don't think we need to be that subtle in the index). [242:27] Added the phrase to the end of the sentence instead, as I think it reads a bit better that way; also omitted the commas. Maybe I should have done the same to [134:35] and [196:6]? 211r1: [383:34] Swapped the two different forms in the heading to improve typesetting. [384:17] Added "error termination" to the index here. EXTRA: [324] Add ORDERED argument to REDUCE entry in the table. [384:7+] Add description of ORDERED argument. [384:14-15] "x,y" -> "x, y"; also change r, x and y to italics since these are not arguments or actual things but virtual things (we usually use italics for those, e.g. for "n"). [throughout] Added ", ORDERED = ORDERED" to the argument lists where I thought it was needed. END EXTRA ACTION: Consider indexing "error termination" everywhere it appears, and maybe hyperlinking it back to clause 2? 153r1: [478:26] Omitted as another paper got to this first. 162r3: Done without modification. 206: Done without modification. 207r1: [144:end-8,end-3] First change already done (whilst entering 188r1?), second change "are" -> "is". Also changed en dash to minus sign while I was looking at it. [237:11+3] I previously did a completely different (and better) fix. [260:7+1-2] Also deleted NOTE 10.23 at [260:4+1-2] for the same reason. [303:end-6] I already did this. [314:37] This reminds me that SOURCE= is not properly defined as a specifier in the LaTeX source... ACTION: Make SOURCE= a "proper" specifier (e.g. using \defspecifier), hyperlink all references to it, index significant refs to it. [463:4] I already did this (as an extra edit while entering 202). [478:26] I already did this (it was in 139r3). [502:22,24] I already did this (it was in 139r3). Finally: Updated the date in the headers, and the page footer to 14-007r2. ===END===