J3/02-275 Date: 23 Sep 2002 To: J3 From: Richard Maine Subject: Edits incorporated in 02-007R3 The editor expresses his thanks to the review subgroup (John Reid, Dan Nagle, and Van Snyder) for their assistance in reviewing his work on these edits (and for catching the embarrasingly many errors that the editor initially made). This paper describes the changes in J3/02-007R3 relative to the previous f2k draft, J3/02-007R2. All page/line references are to J3/02-007R2 unless otherwise noted. Comments from the editor are in a separate paper; this one is restricted to changes made. This includes edits from papers (all 02-): 212, 214r1, 215r2, 216r1, 217, 218, 219r2, 220r1, 221r2, 223r1, 224r2, 225r1, 230r3, 234r1, 236, 238r2, 239, 240r1, 241r4, 242r2, 244r2, 245r2, 246r1, 247r1, 248r1, 249r1, 250r1, 252r2, 253r2, 254r1,255r1, 257r1, 258r1, 259r1, 260, 261r1, 262r1, 263r1, 264, 265, 266, 267, 268, 269r1, 270, 271r1 The following papers were done as is: 212, 214r1, 218, 220r1, 221r2, 223r1, 225r1, 234r1, 236, 246r1, 248r1, 253r2, 255r1, 257r1, 258r1, 260, 261r1, 264, 266, 265, 267, 269r1, 270 The following papers were done with changes as noted. All of the changes done were on the order of typographical errors. Two were to fix incorrect typographical style in the use of colons; other than those two, I haven't even attempted to fix questionable grammar (since doing so can change technical meaning - as illustrated by some of my comments in a separate paper). There were also some cases where the exact intent of J3 was unclear and I have documented the guess that I made. paper 02-215r2 Did not double the comma (clearly a typo). paper 02-216r1 Also removed it from the index. I believe that was the intent, but it was not made explicit in the edit. Although it is possible to remove the bold without removing the index entry, I doubt that was the intent. Indeed, the bizarre index entry was the main subject of the original question. paper 02-217 Changed "and" to "but" and "context" to "contexts" per review subgroup. paper 02-219r2 [43:31-44:5] Internal evidence suggests that the 44:5 was a typo for [44:3], as the next edit would otherwise be to a deleted line. Another paper later deletes [44:5], making that part of the issue moot. Did not delete [44:5]. Applied the edit to it instead. Review subgroup agreed. [45:20] The constraint on this line is C458 rather than C457. I assume, based on the material, that the line number, rather than the constraint number, is correct. There is no explicit bnf definition of or (they are cases of the implicit *-name rule), so several \si in the tex source needed to be \sinr. This disinction is invisible in the printed version of the paper, but it matters for the LaTeX. paper 02-224r2 [260:19-20] Paper 02-244r2 made a different edit in this same place. I assume that the edit in 02-224r2 overrides, as it was passed later. paper 02-230r3 I assume that the para starting NOTE: is intended to be an informative note rather than normative text that actually says "NOTE:". The material reads like a note, so I'll assume that was the intent. Entered it that way. Fixed "; However" -> "; however" [383:14-17] I don't know what it was intended for me to do with the two cases here. Sort of looks like they go under the SHAPE argument, but that is nonsense. There isn't any place much more sensible to put them though. I just put them dangling not under any heading. This doesn't match either the way we have done any other procedure descriptions or the way that ISO (or anyone else) asks that sectioning be done, but I can't figure out what else might have been intended. I omitted the period from the section titles in Annex C. I also omitted some of the colons before code sample, depending on the grammar of the lead-in. paper 02-238r2 [81:14-17] I avoided doubling the "be", the "an", and the period. I believe these to be typos. [253:25] I avoided doubling the comma (presumed to be a typo). paper 02-239 [194:10+] Fixed in a prior paper. [523] I'm not sure what makes this different from the other Annexes (very messy TeX stuff). I hacked it so that there is no run together here, but that makes extra space in all the other Annex headings - I guess extra space is better than the overlap. paper 02-240r1 The material deleted by the 4th edit included an index entry (for attribute!POINTER) that was omitted from the tex of the replacing new para. I assume this was accidental (and that reviewers didn't even look at the tex). I moved this index entry to the new para instead of deleting it. [257:20] This was changed by some other paper. paper 02-241r4 Did not duplicate "for a procedure" in the 19.5+ edit. (Clearly a typo). [416:24] Also added the 2.5.1 xref since this isn't now just a "see" entry. The answer to the question about a grave accent on 24:7 is yes; I've done so (with Van's help). paper 02-242r2 [33: Note 4.1+1] According to the author, the explanatory "{No, correct as it stands}" was supposed to replace the editing instruction, but failed to do so because of a typographical error. I thus obeyed the "No" part instead of the edit. [43:14] Added a "be" to make the sentence parse per review subgroup. [44:4,5] This duplicates an edit in another paper. [47:20] Did not double the period. [61:11] Also did "a" -> "an". [74:33-34] This is phrased as a comment instead of an editing instruction. I believe it was intended as an instruction to change the obsolescent type to normal in these lines. paper 02-244r2 257:20 I wasn't entirely sure whether it was intended that I take this edit literally (just delete) or to turn it into the index entry that this was originally a typo for. Based on the observation that this would have been the only subindex entry under "name", I decided to take the instructions literally. (One could argue for having many such entries for names of various entities, but it seems odd to have only that one). 260:12 There is no "}" to delete. (Presumed typo) 260:19-20 See comments on paper 02-224r2. paper 02-245r2 [277:7-8] Italic for both cases of proc-language-binding-spec. (Clearly a typo). paper 02-247r1 [46:5] I originally thought this trivial edit was a major technical blunder (as the resulting "Its" would have refered to the wrong thing). However consultation with two subgroup members revealed that it was instead a simple typo in the line number. Although there is an "A" on line [46:5], it was the one on [46:6] that was intended (and is so indicated on their hand-marked papers as opposed to the electronic one). I made this correction. paper 02-249r1 The paper says that 2 deep references to 13.8.3.1.3 "should" be changed to 13.8.3 for consistency, but this wasn't mentioned in the "proposed edits". It wasn't entirely clear to me whether the intent of J3 in passing the paper was to do these changes or not. I guessed not, but I'm far from sure of that guess. (They do seem like plausible changes - either that, or the various other references to 13.8.3 might be made "deep" ones, much like most of the references to intrinsic procedures in 13.7.x). paper 02-250r1 [263:Note 12.14] I'm not sure of the intent here in regards to blank lines. It sure looks funny and probably not as intended if I take the edits completely literally. I'll assume that the edits also intended me to adjust blank line usage to one of several plausible styles. I did so. [394:11-12] I'll assume the deletion of the comma was a typo; left it in. paper 02-252r2 I'm not sure what the bold for dtv was intending to indicate. Code font is already (semi?-)bold. I'll assume the bold was just a redundant indication of that, so I ignored it. LaTeX by default put the multi-level item xrefs like 3a, which I can easily enough put parens arund to make (3a). I didn't try to figure out how to force it to make (3)(a), which is probably possible, but not worth the work. (Of course, I could just type in the numbers directly - as I see was done in the deleted note, but then that would break on any renumbering). paper 02-254r1 [20:20] Also added the necessary comma. [430:31] Also changed "an" -> "a". paper 02-259r1 [46:Note 4.21] The first line in question was deleted by a previously passed edit in paper 02-247r1. I assume that the code font edit for dim was intended to apply to both lines 16 and 18, so I did so. [219:5] Our usual definition macro also creates an index entry. I guessed that was also desired here, so I did so, rather than just bolding the text. [249:7] Fixing this also changed the strange index entry for "*PUBLIC statement" to a reasonable one without the "*". I don't think the index got much review, just like it hasn't gotten much attention all along. But then doing a good index is a big job in itself. [266:14] Made the same change at [266:8]. [xiii:10] Done in some other paper. [xii:21] I see no "derived type" on line 21 or anywhere in the area. Not done. There is a "deferred type" on line 21; that might have been what this referred to, but hyphenating that would be incorrect (and changing it to "derived-type" would also be incorrect). I also fixed a particularly egregious similar missing hyphen in the index (see above comments). Changed "derived type type specifier" to "derived-type type specifier". One could argue for also deleting the second type, but I didn't do so. The former "type type" stood out pretty badly. Also fixed another index entry "derived type" -> "derived-type" in the subentry under "resolving procedure references". [77:17] This sentence deleted by another paper. Didn't put any of the colons after "then" or the one after "defined". They are grammatically incorrect, contrary to ISO-specified style, and inconsistent with usages elsewhere in the draft. (this is the biggest place where I made grammatical corrections as editor). I note J3 concurred with JOR's rejection of changes to insert colons on 11:50 and 13:9-13 (at least I assume that is what was proposed there). I concur with J3 and JOR's rejection of the colons there, and I consider my rejection of the colons in these additional places to be consistent. I believe that J3/JOR likely overlooked the similarity of these edits because they were listed under the heading of "If-then English statement" instead of under the heading of "Punctuation For Displayed Lists". Yes, some lists use colons and others don't, just like some instances of "derived type" are hyphenated and others aren't. The draft may well have errors in this area, just like it did for "derived type", but it is not the correct fix to add colons to all displayed lists any more than it would be the correct fix to hyphenate every occurrence of "derived type". The third "only" change on page 274 is a contradictory edit to the same line. It proposes moving the "only" to a different incorrect place, giving a different incorrect meaning. I can't move it to both places, so I didn't do this one. paper 02-262r1 [219:1] This one was also done in another paper. paper 02-263r1 [13:7] I'll assume that the omission of "block" after "abstract interface" was a typo, so I fixed it. An interface block is not an abstract interface, though it may contain such. See 12.3.2.1. paper 02-268 [62:22] There is no such bnf term as . I assume this was a typo for . Fixed. paper 02-271r1 [264:32] Omission of the word "specific" assumed to be a typo. [293:27-28] Omission of "or" assumed to be a typo. Things not in papers. Added Kurt's macros for bnf xrefs. No visible effect on current document, but facilitates such xrefs either as another annex or a separate paper. Three unrelated typos found by the review subgroup [261:Note 12.10] Remove extra blank before "END INTERFACE" [263:Note 12.15] "ISO_C binding" -> "ISO_C_BINDING" [381:Note 15.2] "ISO_C" -> "ISO_C_BINDING"