From owner-sc22wg5@dkuug.dk Mon Jun 16 22:36:37 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h5GKabpO002855 for sc22wg5-domo; Mon, 16 Jun 2003 22:36:37 +0200 (CEST) (envelope-from owner-sc22wg5@dkuug.dk) X-Authentication-Warning: ptah.dkuug.dk: majordom set sender to owner-sc22wg5@dkuug.dk using -f Received: from mailhub.dfrc.nasa.gov (mailhub.dfrc.nasa.gov [130.134.81.12]) by dkuug.dk (8.12.8p1/8.9.2) with ESMTP id h5GKZ2Ec002835 for ; Mon, 16 Jun 2003 22:36:31 +0200 (CEST) (envelope-from maine@altair.dfrc.nasa.gov) Received: from mail.dfrc.nasa.gov by mailhub.dfrc.nasa.gov with ESMTP for sc22wg5@dkuug.dk; Mon, 16 Jun 2003 13:32:22 -0700 Received: from altair.dfrc.nasa.gov ([130.134.20.211]) by mail.dfrc.nasa.gov (Post.Office MTA v3.5.3 release 223 ID# 0-71686U2500L200S0V35) with ESMTP id gov for ; Mon, 16 Jun 2003 13:34:53 -0700 Received: from altair.dfrc.nasa.gov (localhost.localdomain [127.0.0.1]) by altair.dfrc.nasa.gov (8.12.8/8.12.5) with ESMTP id h5GKYsnl029027 for ; Mon, 16 Jun 2003 13:34:54 -0700 Received: (from maine@localhost) by altair.dfrc.nasa.gov (8.12.8/8.12.8/Submit) id h5GKYsO3029023; Mon, 16 Jun 2003 13:34:54 -0700 From: Richard Maine MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="U+DnU/dMrm" Content-Transfer-Encoding: 7bit Message-Id: <16110.10734.373866.72097@altair.dfrc.nasa.gov> Date: Mon, 16 Jun 2003 13:34:54 -0700 To: sc22wg5@dkuug.dk Subject: ISO_FORTRAN_ENV X-Mailer: VM 7.07 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid Sender: owner-sc22wg5@dkuug.dk Precedence: bulk --U+DnU/dMrm Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Enclosed find a draft of N1543, which is a minor revision of N1529 to incorporate some suggestions. The only changes are 1. Put explanations after the edits instead of before them in part IV. 2. In part IV, the edit for [300:10-11] is slightly different. 3. Fixed a typo in the line number of the last edit. At John's suggestion, I'm calling this a draft so that we don't need to get yet another WG5 paper if there are further changes. (I'm a litle slow in picking up how to best work with the WG5 rules on paper number bookkeeping, but perhaps I'm getting closer with John's help). --U+DnU/dMrm Content-Type: text/plain Content-Description: N1543.txt Content-Disposition: inline; filename="N1543.txt" Content-Transfer-Encoding: 7bit DRAFT 16 JUN 03 ISO/IEC JTC1/SC22/WG5 N1543 ISO_FORTRAN_ENV Richard Maine This is a revision of N1529. Three of the new intrinsic functions addded 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, depending on whether or not parts 2 and/or 3 of this paper pass. If part 2 or 3 of this paper passes, then insert a section heading "13.8.2.1 Named constants in the module" If neither part 2 nor 3 passes, do not insert the heading because we should not have a 13.8.2.1 without a 13.8.2.2. (That's an ISO guideline that we don't follow as consistently as we should.) Instead, promote all the 13.8.2.x.x subsections up one level. In either case, insert the following para, either as the sole para of 13.8.2.1 or as an additional para of 13.8.2. "The processor shall provide the named contants described in the following subclauses." II. Move the new functions. The IS_IOSTAT_END and IS_IOSTAT_EOR functions seem quite appropriate for ISO_FORTRAN_ENV. They concern system-dependent aspects of the Fortran I/O environment. Indeed, they are so closely tied to the IOSTAT_END and IOSTAT_EOR constants that I can't figure out any good justification for them not to be in the same module as the constants. The only "justification" I can think of is one that I wouldn't classify as good: if someone thinks that we shouldn't have procedures in intrinsic modules, then they are a bit late for that objection - we'd have to substantially redo the IEEE_* and ISO_C_BINDING modules. The NEW_LINE function also inquires about a system-dependent aspect of the Fortran I/O environment, fitting well with the other things in ISO_FORTRAN_ENV. EDITS: [235:2] "intrinsic" -> "module" [363:3+] Insert new subsection (it will be either 13.8.2.2 or 13.8.2.4, depending on whether or not part 1 passes) "13.8.2.x Procedures in the module The processor shall provide the module procedures described in the following subclauses." [327:2-15] Move these (13.8.7.57-58) into the new 13.8.2.x in alphabetic order. [341:14-26] Move this (13.8.7.85) into the new 13.8.2.x in alphabetic order. [394:Note 15.3] The xref for NEW_LINE will automatically renumber. [298:17] Delete line for NEW_LINE [300:10-11] Delete lines for IS_IOSTAT_END and IS_IOSTAT_EOR. III. Move other procedures This also seems like an appropriate time to review whether COMMAND_ARGUMENT_COUNT, GET_COMMAND, GET_COMMAND_ARGUMENT, and GET_ENVIRONMENT also belong in ISO_FORTRAN_ENV. I think they do, but I probably suggested that before and failed to generate enough support to make it happen. However, the decision might well be different when looking at the standard as an integrated (well, as much as we can) whole than it was when looking at the individual procedures. I'm not sure that we ever stepped back and looked at that larger picture of integration. Can anyone look at a procedure named GET_ENVIRONMENT_VARIABLE and fail to wonder why it isn't in the module named ISO_FORTRAN_ENV? Note that putting these procedures in the module would not invalidate any existing early implementations that might already provide them as intrinsics; it would still be valid for an implementation to have them both ways, with the intrinsic procedure version as a processor-defined intrinsic. One widely used existing implementation (f2kcli) already does these procedures in a module. In the abstract, I'd also think that module a good place for CPU_TIME, DATE_AND_TIME, and SYSTEM_CLOCK, but it doesn't seem worth either the incompatibility with f90/f95 or the complication of doing them both ways, so I don't propose that. EDITS: [300:4,6.5-9] Delete the lines for COMMAND_ARGUMENT_COUNT, GET_COMMAND, GET_COMMAND_ARGUMENT, and GET_ENVIRONMENT_VARIABLE. [310:17] This xref will auto-renumber. [363:3+] If part 2 didn't pass, we need to do the [363:3+] edit from it anyway for part 4. [310:8-17] Move this (13.8.7.21) into the new 13.8.2.x in alphabetic order. [319:6-321:4] Move these (13.8.7.41-43) into the new 13.8.2.x in alphabetic order. [486:28] "intrinsic" -> "module" 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 contition. 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:8,15] Change both xrefs to 9.10.4, which is the section on IOSTAT=. {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 module 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 splitting 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 inquiry function NEW_LINE (13.8.2.2.3), {I'd think people likely to want to use NEW_LINE in initialization expressions. I see no reason to prohibit this.} [235:3] After NEW_LINE add " (13.8.2.2.3)". {An xref here seems like a good idea. Adjust as appropriate.} --U+DnU/dMrm Content-Type: text/plain; charset=us-ascii Content-Description: .signature Content-Transfer-Encoding: 7bit -- Richard Maine | Good judgment comes from experience; Richard.Maine@nasa.gov | experience comes from bad judgment. | -- Mark Twain --U+DnU/dMrm--