J3/03-205r1 Date: 19 August 2003 To: J3 | From: Richard Bleikamp Subject: ISO_FORTRAN_ENV Re: WG5/N1543 ISO/IEC JTC1/SC22/WG5 N1543 ISO_FORTRAN_ENV Richard Maine | JOR changes are marked on the left with "|". This is a revision of N1529. | Three of the new intrinsic functions added at the previous J3/WG5 meeting are, in my opinion, more appropriate in the ISO_FORTRAN_ENV module than as intrinsics. This paper addresses that and some issues that came up while looking at that. The four parts of this paper are more or less independent. Any combination of the four parts could plausibly be passed with at most minor adjustments in the other parts. I. Simplify organization of 13.8.2 The 13.8.2.x subheadings don't add much in my opinion; I think them of negative value. They just make the important stuff harder to find. They don't stand out well from the next level of subheadings under them. Indeed, because of the capitalization conventions, the 13.8.2.x.x subheadings look more prominent than the 13.8.2.x ones. The text in the 13.8.2.x.0 sections is mostly fluff and wouldn't be missed; only the xrefs from it seem worth keeping. Therefore: EDITS: [361:29-31] Delete subsection 13.8.2.1, including its heading and body, but not including the subsections below it. [362:3,7,11] Before "." insert " (9.4)". (3 times) [362:13-15] Delete subsection 13.8.2.2, including its heading and body, but not including the subsections below it. [362:18,22] After "specifier" insert " (9.10.4)". (twice) [362:25-27] Delete subsection 13.8.2.3, including its heading and body, but not including the subsections below it. [362:1-363:3] Alphabetize and appropriately renumber all the 13.8.2.x.x subsections. | [361:28+] Insert the following Promote all the 13.8.2.x.x subsections up one level. Insert the following para as an additional para of 13.8.2. | "The processor shall provide the named constants described in the following subclauses." | II. Move the new functions. DELETED | III. Move other procedures DELETED IV. Other trivial fixups to the new functions I recommend the following minor editorial fixups to the descriptions of the IS_IOSTAT_END, IS_IOSTAT_EOR, and NEW_LINE functions, whether they move into the module or not. [300:10-11] "condition" -> "value" (twice) {If part 2 passes, the above edit is moot. If part 2 does not pass, these lines should be made correct. These functions do not, in fact, test for an end-of-file or end-of-record | condition. They test an integer value, which might or might not have come from an IOSTAT= specifier. You could get a true result from these functions without any I/O ever having been done.} [327:3,10] "the argument" -> "a" {Wording simplification.} | [327:3,10] "and" -> "an" [327:8,15] Change both xrefs to 9.10.4, which is the section on | IOSTAT=, and move the xrefs earlier in the sentences just | after "specifier". {Sections 9.10.2 and 9.10.3 on END= and ERR= are only peripherally related, and indeed actually in turn reference 9.10.4 for the appropriate material.} [327:7-8,14-15] "that would be assigned to" -> "for", and "to indicate" -> "that would indicate" (twice) {To me, the wording of the result value clauses almost make it sound like the programmer could cause a condition to be signaled by setting the variable to these values.} [341:24] "The" -> "Otherwise, the" {As is, case 3 is interp bait. Does it imply "or", "and", or "otherwise"? It makes a difference. Let's say now instead of in the interp answer.} [341:25] "one" -> "such a character" {One what? File connected for formatted stream output?} [235:Note 10.17] Replace note body with | "If the intrinsic function NEW_LINE returns a blank character for a particular character kind, then the processor does not support using a character of that kind to cause record | termination in a formatted stream file." {If we want to have Note 10.17 at all, it would be good for it to make sense. I don't know what field it is talking about splitting; I think it means record splitting. And I'm not sure whether the statement otherwise is a tautology or a contradiction. In one sense, if the processor actually supports the newline character as something that could be written as part of the data in a record, that would be the case where the newline character could *NOT* be used to split records, making the statement a contradiction. In another sense, it is a tautology that you aren't allowed to do something (write the character), then you aren't going to be able to split records by doing it. Let's just say what we mean; it isn't very complicated - either that or is is so complicated that I don't yet understand it.} [127:41+] Add list item (Adjust xref as appropriate.) | (4a) the character inquiry function NEW_LINE, | {I'd think people are likely to want to use NEW_LINE in initialization expressions. I see no reason to prohibit this.} | {JOR deleted the edit to 235:3} | [203:22+5] replace "13.8.2.1" with "13.8.2" | [213:9] replace "13.8.2.1" with "13.8.2" | [417:38] replace "13.8.2.3" with "13.8.2"