09-156 To: J3 From: Malcolm Cohen Subject: Editor's report for 09-007r1 Date: 2009 March 25 1. Additional editorial changes ------------------------------- Hyperlinked and indexed (or improved thereof): "argument keyword" "cosubscript" "declared type" "defined operation" "elemental" "image" "line" only within clause 3. Maybe the term should have been "source line" instead (in which case it is close enough to general usage not to need to be a special term). "NaN" "pointer assignment statement" "polymorphic" "pure procedure" "scoping unit" "STAT_STOPPED_IMAGE" "statement keyword" "structure constructor" "type parameter keyword" "unit" (i.e. input/output unit) Also, many constructs and statements have been hyperlinked and indexed. Eliminated excess indexing in the syntax rule index. In c08, "GOTO statement"->"GO TO statement", twice. Added cross-ref to {D16:Pointer association status} in the definition of the term "defined" of a pointer. Changed all 2 occurrences of "pointer-associated"->"pointer associated". In C_FUNLOC, "implicit-interface procedure pointer component PX" ->"procedure pointer component PX wiht an implicit interface". {We don't use "implicit-interface" anywhere else.} In "The FORALL statement", added "statement" after "pointer assignment". Deleted "module procedure interfaces" from the list of class (1) names in c16; I leave it as an exercise to the reader to prove it was redundant. Changed all "is processor-dependent" to "is processor dependent" (well, all the ones I found anyway); we used both forms but the latter was more prevalent (62:11 not counting ones broken across lines) and is more consistent with our hyphenation "policy", such as it is. [c08 somewhere in a note] "image value"->"image index value". [ditto] "on any of the other images"->"on any other image". [25:1] Deleted "terms and" (the terms are now in clause 1). [25:3] "terms"->"syntax". Maybe it should be "syntax terms", but plain "terms" just seems wrong. [45:9-10] "default kind characters"->"characters of default kind" for consistency with the wording at [43:22]. [75:2-3] There is no such thing as an END PROGRAM statement, reworded to use the syntax term instead. [189:15+9,29] There is no such thing as an END PROGRAM statement, reworded to use the syntax term instead. [335:22] Revise description (edit missing in 09-007). [386:15-17] Reworded to improve typesetting and consistency. [404:6,405:21] "kinds of a"->"a kind with" (larger size); otherwise it could be read as applying when more than one kind (with larger size) is supported rather than one or more. [416:5] Inserted an indefinite article. Now the sentence is grammatical; it is still wrong though. [416:28] Delete excessive vertical space and extraneous paragraph number. [417:6] Delete excessive vertical space and extraneous paragraph number. [417:19] Delete excessive vertical space and extraneous paragraph number. [418:27] Removed extra parenthesis. [419:4] Removed extra parenthesis. [419:4-5] Didn't change this, but does IEEE_SUPPORT_SQRT really require (and/or imply) IEEE_SUPPORT_NAN? Daft. [419:19] Reworded to match the phrasing used in similar cases nearby. [511:34] Moved to [511:37+] (was out of order). [535:5,10] "has"->"had" to improve grammar. If the main verb is conditional ("had") the governed verb must be subjunctive (viz "would be" not "is"). [535:9] Removed tildes. [535:10] Re-typeset to avoid overlong line and "value" too close to "[". [535:14] Revised spacing. [535] Rewrote C.13.3.6-7 to simplify and use maths for the mathematical content. Removed last sentence of C.13.3.7 as it is not about matrix norms. I wonder why we only provided NORM2 for REAL and not COMPLEX. [c14 throughout] Formatted: (a) inserted blank between name and left parenthesis of function reference (to match our normal style outside of code font); (b) inserted blank between comma and following argument ditto; (c) turned several hyphens into minus signs. This does make things take up more room, but they are more readable apart from being stylistically more consistent. [c13 throughout] Similar changes and various spacing tweaks. 2. Editorial Suggestions for Further Consideration -------------------------------------------------- It seems to me that "operand" and "operator" are normal usage. Can we not just delete these terms? 3. Comments re Indexing ----------------------- I have two families of macros that I use for hyperlinking, one adds an index entry, the other does not. Defined terms should always be hyperlinked. Whether each occurrence should be indexed is another question. My general guideline is that if the text is about the term, concept or feature itself, it should be indexed. If the text is about a "canonical" usage of the feature, it should be indexed. If it is a trivial usage of the term that throws no light on its meaning or use, it should not be indexed. There is a wide grey area between canonical usage and trivial usage, where judgement is required. I'm sure that occasionally in a long indexing session I have gone into a sort-of-autopilot "index everything" mode. It would probably be a good idea to remove some of the less useful of those index entries, especially for those terms which have a very long list of entries (if the list is short it doesn't matter so much). In general, when in doubt I have indexed it (it is easier to notice unnecessary index entries than to spot ones that are missing!). Any suggestions as to removal of extraneous entries or addition of new entries will be given due consideration. 4. Rejected papers ------------------ 115r1s3 REJECTED. This change appears to be an incomplete addition of a new feature. 5. Passed papers with commentary -------------------------------- 103s3 104 last paragraph only. 105s2 applied as amended: after "editing done by" inserted additional "the". "scale factor effect" -> "effect" etc. {The lead-in sentence says this is how k affects the editing.} 106r1 applied with the list items joined to the previous list. 107r1 aa Added index entry for I/O rounding mode to IEEE_SUPPORT_IO. 110 revised appearance. 112 Removed UTI 162. 113r1 Also [39:7] unemboldened "Fortran character set" and indexed as definition; (missing edit - the witter at the top said we would determify it though). Added cross-ref to the edit at [58:3]. 114r3 [268:24] There's no such thing as a "". There are "" and "", but not "". Rewrote the offending sentence. Rewrote the "Subscripts" sentence into the singular. Simplified the "derived type" sentence; changed "the name in the input record" to "the designator in the input record" (bug). A "zero-sized array section" *IS* a "zero-sized array", but I did not remove this redundancy. [269:1-3] Again, no such thing as ""; reworded. EXTRA EDIT: [269:21] After "name-value", "sequence"->"subsequence". [269:20-21] Again, no such thing as ""; reworded. 116r1 117 In the second edit, changed ATOMIC_INT_KIND to KIND(VALUE). Removed UTI 154. 118r1 Having a subclause that is just a syntax rule and a constraint is pretty bad style, so I added a sentence to introduce it. I still don't like the name of the syntax term. 119r3 Changed one "can" to "could" in the note. 121r1s3 [436:22] Instead, just deleted "contiguous" (we still need to require it to be a variable). A couple of commas already existed so I didn't insert extra ones. 122r1 parenthesised cross-refs in binding, binding name. fixed extraneous R at [13:11]. Also indexed "imaginary part" as definition. Improved hyperlinking/indexing of "kind type parameter" in c04. Didn't do [104:28(5.4.7p9)] After "compatible" insert "(4.5.4.6)", cross-ref appears later in the sentence. [113:22] Deleted duplicate cross-reference. 123 124 125 [141:16(7.1.5.1,title)] different capitalization [167:21] Reworded. 126r1 It turns out we used "branch target statement" with two different meanings: (1) statement that is permitted to be the target of a branch, (2) statement that is actually the target of a branch; rewrote the term definition so it works for both of them. Changed several cross-references to "D8:Image control statements" to reference the new "D8:Segments" instead. 127r1 "defined input/output" already existed as a term, but was not properly hyperlinked and the definition was not as good. The definition of the term "record" is somewhat lacking and needs improvement. [199:9(9.1p3)] Hyperlinked the keywords to the statement subclauses. Indexed all of 9.5 "File connection" for "file connection". Indexed "wait operation" everywhere it appeared in c09. Hyperlinked several of the i/o statements. 128 129r1 130r1 [277:9-10] didn't insert 12.6.2.5 because we already did it earlier in the paragraph in the precious edit. Also reworded C1247 and C1248. Changed a lot of "within the in" to "in the of". Changed "length of the abstract" to "length of the synopsis" in a note. 131r3 [88:20-21 5.3.4 ASYNCHRONOUS attribute] I think the proposed edit made the text more confusing, so I changed it the same way I did for VOLATILE below. [100:6-8 VOLATILE attribute] The first sentence is practically vacuous, I added some more worms; these need to be reviewed. Furthermore, the forward reference to pointer assignment is wrong. This needs more work: added UTI 163. [101: NOTE 5.25] Deleted the note instead: see comment for 455:1. [301:9 12.5.2.8 Coarray dummy variables] Also additionally moved p2 to follow p1, so that the notes are all at the end. Since notes 12.30 and 12.31 are big, and para 2 is small, there was a significant chance of someone not noticing para 2 while reading. In fact para 2 seems to be technically wrong, so I added UTI 164. [455:1 16.5.2.1 General, para 1] Absolutely no way am I adding this junk here. What was I thinking when I voted for this (I must have been asleep)? It is in no sense "General" "Pointer association" stuff. It's VOLATILE stuff guys, it only occurs *when the target is VOLATILE*, it belongs in the *VOLATILE* attribute subclause. It belongs right next to the sentence saying "should have the VOLATILE attribute", so I have put it there. That's another thing that needs review. Broke the now-huge paragraph 2 about VOLATILE into paras 2-4. Appended the last two paragraphs, which are about what VOLATILE means, rather than requirements, to the first paragraph which is also about semantics. All these editorial things are IMO an obvious improvement, but they do need reviewing (many comments added to the new UTI 163). Deleted UTI 153. 132r1 133 [411:29(14.8p2)] Singularised replacement and index definieiyt. Extra: Rewrote 14.11.1p1 to remove unnecessary complexity. Rewrote 14.11.1p2 to fix bug (it implied that IEEE_IS_FINITE should return true for an Infinity!) and remove unnecessary xref. Moved note 14.8 to the end of its subclause, changed "a call" to "an invocation" to match the wording in the actual restrictions better, and make more sense for functions. Actually, the wording of this note is poor anyway. [14.10.2-14.10.6] Various minor wording improvements to some functions. 134r1 Also fixed up many hyphens that were supposed to be minus signs. 135 Removed existing Note under "association" re name association (not needed now it is properly defined). "statement entity" already existed, so I didn't add it. Indexed: deferred type parameter (was only partially done before). Added definition for "construct association". Hyperlinked "preconnected". 136 with alternative edit The bad page break turned out to be a bug in j3.cls (the macro \dcons). 137r2 [156:19(7.2.1.3p3)] Changed first "" to "the variable", deleted "as " from the insertion (what else could it be the same as?). [268:25(10.11.2p3)] Followed the namelist comment suggestion. Also, lowercased "Comments" in the referenced subsection. [272:3,6(10.11.4.1p1)] Merged edit with that of a previous paper. 139 [51:11+] Inserted subclause heading "General". Index the whole of the new subclause as the definition of "numeric type" (a defined term). 141 Removed UTI 151. 142r2 Removed reference to the deleted section in c01. Deleted UTI 155-158. I did not carefully recheck all the issues have been properly handled. 143r3 [404:22-23] Only deleted two sentences, I couldn't find a third one to delete. Deleted UTI 161. 144 145s2 "" was too long for our fixed space on the left-hand-side for BNF definitions; rather than increase this space, changed it to "". 145s3 Did all this conditionally - switching between "constant expression" and "initialization expression" is a one-line change in 007.tex. With "constant expression", the hack for default-char-init-expr is no longer necessary, it becomes default-char-constant-expr. 146 147r2 The edits in this paper were quite difficult to follow. Also fixed reference at [196:5] to be more specific. Put some of the statement lists into a semblance of alphabetic order. Indexed all of 8.5.7 for "STAT= specifier" and "ERRMSG= specifier". Deleted UTI 159. UTI 160 has not been entirely answered - the erroneous note has not been dealt with - so I have modified it instead of deleting it. 151 Deleted UTI 152. 138r2 [100-101: Notes in the middle of VOLATILE] Already done. [122:7-8] Also changed the definition in c01, using very different wording. Someone else should check it. [122:10-11] Also replaced nearby "whole array variable"->"whole array designator". [215:1+] Inserted the constraint at 35+ instead (the intervening constraints mostly applied to the earlier syntax rule, so this belongs later). [267:5] Added to the middle not the end of the paragraph, i.e. before the addition in another paper. Deleted "input/output" before "file positioning" (there ain't no other kind of file positioning operation). [294:3+(12.5.1 C1229+)] Used indefinite article instead of definite, for consistency with nearby text. [463:43-44] First "allocation"->"execution". [361:12] Reworded to improve typesetting. ===END===