J3/00-230 Date: 12 Jun 2000 To: J3 From: Richard Maine Subject: Edits incorporated in 00-007R2 This paper describes the changes in J3/00-007R2 relative to the previous f2k draft, J3/00-007R1. All page/line references are to J3/00-007R1 unless otherwise noted. All of the changes mentioned in this paper have been done in the draft. Although there may be some questions raised below, they do not necessarily require action in my opinion. Those issues which I believe to require action have been put into a separate paper of unresolved issues for addition to the 011 document. This was done to help highlight and track the items requiring action. Ths change bars in 00-007r2 are relative to 00-007R1. This includes edits from papers (all 00-) 169r2, 171r3, 172r2, 173r1, 174r1, 175r1, 176r2, 177, 178r3, 182r1, 183r2, 184r2, 187r1, 195r2, 196, 198r1, 199r1, 200r3, 207, 211, 212, 215, 216, 218r1, 219, 220, 222, 224, 225r1 Typos pointed out to me at the meeting, but not in papers [388:15] "USE_ISO_C_BINDING" -> "USE ISO_C_BINDING" [391:22] "explict" -> "explicit" paper 00-169r2, with the following changes [115:16-17] Used ", which is" where it fit to shorten things. paper 00-171r3, with the following changes (The "r3" is formed from "r2" as specified in 00-225r1) item 1 - I inserted the note at [71:12+], right below the relevant constraint, instead of at 71:19+. It was confusing at [71:19+] as there was stuff about pointers and procedures right above it, but this didn't relate to that, making it look like a non sequitur. item 3 - Used "it" for the 2nd occurance of . item 6 (from 00-225r1) - Deleted two "the" before bnf terms. And reversed the order of the "or"ed things to put the simpler one first (as they are now unambiguous in either order). paper 00-172r2, with the following changes "interface" -> "interfaces" to agree with "procedures". No colon before the list. During the meeting, I failed to notice the change from "procedure interface block" to just "interface block". I had recalled that we just had a paper to make some such usage consistent and hoped this wasn't undoing the consistency. A brief search found that the paper I remembered was 00-117, which made the usage of "interface body" consistent. Looks like we still need to do the same for "interface block". Much like 00-117 noted for "interface body", there are lots of cases of the string "interface block", but only a very few of "procedure interface block". (And the few exceptions are in the definition - so we basically define a term that we almost never use in the form that we define it. So I'll accept the change made in this paper, and similarly change "procedure interface block" to "interface block" in the places found by grep, namely (some cases in plural, and some cases also changing "a" to "an") [13:3,16], [57:28], [245:40], [443:21,26], [444:18,20,24] While on the subject, fixed the following incorrect uses of "interface block", which ought to be "interface body". (Gosh is the choice of terminology for these bad! Its clear that I'm not the only one that gets them wrong a lot.) [346:44-45,46], [347:1] An interface body has no dummy args, so this was obviously wrong. Nor is it a scoping unit. [401:20-21,22], [402:20-21], [443:21,26], [444:18,20,24], [439:28] And while further on the subject, fix the gramatical number disagreement on [444:18]. paper 00-173r1, with the following changes Combined "procedures or modules" instead of repeating the whole otherwise identical phrase. Delete "whose names". Its the procedure or module that is or is not defined - not just the name. And then it seems better to just xref clause 13 as a whole instead of 4 of its subclauses - the whole clause is, after all, about intrinsic procedures and modules (thus the title). The paper asked whether or not to set two things on bold. It's arguable. If you'd have just put them in bold, I've have accepted that. But since you ask, my recommendation is not to. We have just defined the term "intrinsic", and these terms are just a result of further modifying "intrinsic" with "nonstandard" in the obvious English sense. I don't think this needs citing as a separate definition. So I didn't. We've got an awful lot of typeface changes in the standard anyway - makes it look garish. (Italic, by the way, doesn't fit our conventions - I just set it in the regular font). paper 00-174r1 as is paper 00-175r1 as is paper 00-176r2, with the following changes (The "r2" is formed from "r1" as specified in 00-225r1) Hyphenate "type-bound" in the last edit. paper 00-177 as is paper 00-178r3, with the following changes Also an "a" -> "an" in the first edit. "program unit" -> "scoping unit" in the 3rd edit. The "program unit" was "clearly" wrong. Presumably one would want this to apply to things like module procedures and internal procedures, which aren't program units. I waffled between "scoping unit" and "procedure". I finally put "scoping", but it was a close call. If J3 feels that "procedure" is better, feel free to make that change. And added "in a scoping unit" after "specification expression" in the third edit so that there would be a clear referent for the "the scoping unit". If you change "the scoping unit", probably want to change this also. Omitted the last comma in the last edit. paper 00-182r1, with the following changes I wasn't sure whether or not it might be appropriate to also change some or all of the cases in the last 2 paras of 5.1.1.8. The paper didn't say to, so I didn't. paper 00-183r2, with the following changes Added a comma after "otherwise". paper 00-184r2, with the following changes (The "r2" is formed from "r1" as specified in 00-225r1) Also fix typo "corresponence" at 236:34. (per Van) "insure" -> "ensure" in the edit at [236:29+] (per Van) Instead of repeating the "no more than one" bit three times, said it once as "There shall be no more than one main program argument for each combination of type and rank." right after was say that the use is determined by the type and rank. paper 00-187r1, with the following changes Omit "section" before section refs (twice). ISO is "funny" about this. They really prefer to have nothing here, and if we have to put a word, they want it to be "subclause". paper 00-195r2, with the following changes [102:38+] Change the 2nd comma to an "and". hyphenate "type-compatible". Delete "the" before "". [103:25+] "present" -> "specified" No "the" before "" paper 00-196 as is paper 00-198r1 as is paper 00-199r1, with the following changes "In the example" -> "In the above example" just to make it explicit. Used the code typeface instead of quotes for the variable names cited in the text explanation. paper 00-200r3, with the following changes Fixed spelling of correspondences. The paper was internally inconsistent about whether or not the example code was indented. Yes, so is the standard - we have examples both ways. But at least local consistency seemed desirable. I indented all the example code. I mostly entered this paper by just pulling in the text file and then tagging the paragraph types where needed (after fixing the tabs by turning them into spaces). That makes things easy for me. But it does mean I didn't do as careful a job of proofreading as I typically do while typing. Caveat emptor. paper 00-207 as is paper 00-211 as is paper 00-212 as is paper 00-215, with the following changes [266:19] I redid the wording here a bit (shortened it). It didn't make any sense to say "if a is specified in a ". The in a is not optional, so that part of the condition was irrelevant. [267:1] Also "The" -> "A" [272:11] Fixed typo as pointed out on the floor. paper 00-216 as is paper 00-218r1 as is paper 00-219 as is paper 00-220, with the following changes Also deleted Note 10.20 at 222:3-6. It is now moot (and Frame noticed its unresolved xref to the removed section). Delete "for carriage control" at [229:26 and [234:20]. As with the paoer's two edits in these areas, changed nothing about the behavior, but deleted the now-dangling reference (making it seem even more like a strange requirement, but then it already did seem pretty strange). paper 00-222 as is (Just the edit at the bottom, which is what was passed. Not the other changes that the paper discusses). paper 00-224 as is paper 00-225r1 as is (Just the unresolved issue at the bottom. The other parts were handled as amendments to other papers.)