J3/03-230 Date: 13 Aug 03 To: J3 From: Richard Maine Subject: Editor's action on WG5 papers In order to facilitate rapid turnaround of the edits for the FCD, I have already entered most of the edits from the WG5 resolutions (N1548). My actions, suggestions, and comments on these are described below. The edits I have entered are in no way binding on J3; they are all readily reversable. I have done these with the guess that it will be faster to enter any differences between these edits and those passed by J3 than it would be to start from scratch. I have not released a new 007 with these edits applied because this is far too close to the J3 meeting for such a thing. Nobody would have time to look at it, and none of the edits in pre-meeting papers would be written against it. N1552 (03-211), N1553 (03-212), N1556 (03-213), N1557 (03-214), N1560 (03-217), N1562 (03-219), N1564 (03-220), N1566 (03-222), N1567 (03-223), N1568 (03-224), N1569 (03-225), N1570 (03-226), N1571 (03-227) I. CHANGES MADE Name of the language A WG5 resolution said that the informal name was to be Fortran 2003, but there were no edits to implement this. I think I recall seeing some edits for this from John Reid, but I don't seem to have them handy right now. In any case, they are obvious, so I did them. Changed the 5 cases on pg xiii and the one occurance at [4:26]. Grep reveals no other relevant places where 2000 appears. N1553 (03-212) N1543 (03-205) [127:41+] Different edits were added here by N1539 and N1564. The only difference was in whether to have an xref. I used the N1564 version, which seemed more like the other items in the same list, but either version would be fine. Also fixed xrefs at [203:22+5], [213:9], and [417:38]. N1530 Paper N1553 said to accept N1530 "as is", but N1530 says to do nothing, so that's what I did. I presume that the acceptance indicated agreement with its reasoning; if there was actually some edit I was supposed to make, I missed it. N1556 (03-213) "examples" -> "example" in the note addition. The phrase "for examples" doesn't read right even if there are multiple examples; in this case, there is only one anyway. N1557 (03-214) 03-130r2 - Also changed "The"->"An" on [230:17]. 03-131r1 Used "are supported" instead of "is supported" on [372:4,20]. Fixed unrelated typo ","->"." on [372:16] 03-154r3 [24:17] Also included "the" in the text to be replaced. [143:12] I did the edits labeled as at J3's discretion. N1560 (03-217) II.B. Also changed "Since" to "Because" at [211:Note 9.59] and [493:34]. II.C. Did same change at [105:6] (C111) as for C609 and C610. Looks omitted by accident. N1562 (03-219) After the (R503) is changed to (R401b) in the former C526 [71:20-21], the "in " is redundant. Following the guidance of N1560 part II C, I deleted the redundancy. Note that N1563 incorporates the same deletion; thus it could be said that I followed N1563 instead of N1562 for this edit. N1564 (03-220) [235:Note 10.17] N1564 and N1553 approved different versions of this note. I used the one in N1553 because I believe it to be technically superior, but J3 might review that decision. The edit in N1564 completely ignores the issue of multiple character kinds; whether NEW_LINE returns a blank depends on the character kind of its argument, so it is not meaningful to just ask whether NEW_LINE returns a blank on a particular processor. N1566 (03-222) The WG5 resolution said to incorporate the edits from N1566, but N1566 said to do no edits. I did the no edits as specified. N1567 (03-223) [239:28] Same change as at [228:41]. N1568 (03-224) [53:0+2] Same fix as at [48:0+3] Other purely typographical fixes not in WG5 papers [28:6] Removed an attempt to index the "!" on this line. It never worked anyway, but I just now noticed. Could be put back in if I figure out how to make it work. Since it wasn't working, this edit doesn't actually change the document; just avoids an error message in one of the log files. [50:11] Manually added a "soft" hyphen to avoid the overrun into the right margin. (Also required a minor Makefile change to accomodate soft hyphens in indexed terms). [181:32] Removed extra blank before <>. [267:22+5] Add "Note" before "7.43". This was an eror in entering edits from 03-173. II. FUTHER CHANGES SUGGESTED N1556 (03-213) In the note addition, the phrase "the same" in technical material should usually make one ask "the same as what?" The answer is not explicit here (could be the same as each other). I did not fix that. N1557 (03-214) N1545 - I did nothing about N1545 because both N1557 and personal communications implied that WG5 had not carefully reviewed this material. Therefore, I await J3's action, even if that is just to tell me to go ahead as is. I have no problems with any of the WG5-recommended edits (though I don't understand their question about 413:24; that edit is purely a fix for a runon sentence; it should have no technical impact and is identical in form to a fix previously made to the following sentence. If someone thinks there is a problem with the edit, it can be deleted; it has no relationship to the technical content of the paper.) 03-118r3 - WG5 deferred this to J3 and gave no edits. I did nothing about it (ugliness of Table 7.8 on pg 141 of 03-007). 03-125r1 - WG5 deferred this to J3. I did nothing. My recommendation is to delete "(if any)" at [85:10,12]. 03-154r3 - WG5 says that 03-154r3 says what to do at [351:16+]. However, someone (not the editor) still needs to do it. I don't know how. N1560 (03-217) [69:23] This paper fixed an inappropriate xref here, but I now also find the same bad xref at [62:15] and [430:10]; those should also xref 4.5.6 instead of 4.5.3. [268:Note 12.15] This paper tried to update Note 12.15 to reflect the split of C_FUNLOC from C_LOC. The edit does make the note lie less, but it sill lies. The last sentence of the note is wrong because ignores the possibility of the argument being a procedure pointer. However, the sentence is also completely superfluous now. This sentence was trying to distinguish the function cases from the data cases before C_FUNLOC was split off. With the split, a correct version of this sentence would end up saying that the argument to C_FUNLOC has to be something that is a valid argument to C_FUNLOC, which seems more likely to confuse than to help (people would be bound to wonder what obscure point it was that they were missing). Therefore, I recommend at least deleting this sentence. I would argue that deleting the whole note is better because Note 15.11 says the same thing more generally and in a more appropriate place. N1564 (03-220) [341:21] There is no such thing as the ASCII character 10; 10 is 2 characters. You presumably mean the 10'th character in the ASCII collating sequence, but that is *NOT* what this says. Entered as is, but this is wrong. [341:15] I think this edit inappropriate, but did it anyway. We don't include exceptional cases like this in any of the other description sections. The descriptions are short summaries, not intended to repeat every detail. For a very similar case. the description of CPU_TIme doesn't say "or a processor-dependent negative number if the processor cannot return a meaningful time." Also, the parsing of the "if" condition is ambiguous; it is not clear that it refers only to the "or a blank". N1567 (03-223) [12:27-29] The paper suggests that J3 either delete or fix this. The choice needs to be made and, if the choice is to fix it, a fix needs to be crafted. I'd go for deletion, but the choice is J3's. [454:13] I'm not sure what the request to have J3 review the style of this example is about. Several things in it don't match my personal style, but I doubt that was the point. I did fix the quotes, but that's more of a typo (AucTex mode of XEmacs being "helpful") than a style question. I pass the suggestion to review the style along to J3. N1568 (03-224) [255:11] I didn't do anything about the "more substantial rewording", which this paper said is desirable. I'm not enirely sure what it was aiming at, but I leave that to J3. N1569 (09-225) [105:6-7] WG5 said they were also confused by this. Aleksander once gave an explanation (the details of which I forget) in email, but if both WG5 and me were confused, perhaps J3 needs to look at this to make sure. III. OTHER COMMENTS - NO CURRENT ACTION SUGGESTED N1553 (03-212) I still disagree with the arguments for making functions intrinsic instead of in modules. Seems to me that WG5/J3 are saying that modules are good for users, but not good for WG5/J3. I think this just shows that WG5/J3 haven't yet really figured out why modules were added in f90 and what they are good for. Exactly the same issues apply, whether the functionality is in user code or in the standard. Some of this functionality *IS* currently in widely used user code (f2kcli) and the user understood the language well enough to identify a module as the appropriate packaging mechanism. I also think the distinction between procedures and constants is a completely spurious argument. If we wanted intrinsic constants, we could have them with exactly the same namespace issues as intrinsic procedures have - no more and no less. Fortran doesn't (so far, as of f95) have either intrinsic modules or intrinsic constants; it seems a non sequitur to conclude that this is why we have to put the constants in an intrinsic module. But this is a technical matter and not one worth derailing the process for. Oh well. It's not the worst mistake we have ever made. I'm upset more by the feeling that the committee doesn't understand modules than by the detail of these particular procedures. N1557 (03-214) 03-154r3. WG5 appears to have completely missed the point here. The problem is not with the term "item", but with the term "contain". We have had errata issued against f90/f95 for similar issues. (F90 corrigendum 3, edits on [182]; F95 corrigendum 1, edits on [32:15] and [55:41]). I anticipate a similar erratum on this one. N1568 (03-224) [269:20] I think the antecedant of "it" in this edit is ambiguous; that's why the original text didn't use it. But it will be understood anyway, so it isn't worth contesting. [287:25] Seems to me that this whole constraint is silly. The only thing it does is give constraint status to one particular case of a more general requirement stated at [411:27-28]. Why this particular case deserves such special status I don't know. But although I think it silly, it isn't wrong, and deleting the constraint would be a technical change, so I guess it just stays silly. N1569 (03-225) I still disagree with the claim that inheritance overriding is adequately defined, but I guess that just means extra business for us textbook writers, who can explain what it really means. I suspect it may also mean extra future business for interp; we have had interp requests on things that I thought the standard made far more clear than this.