From maine@altair.dfrc.nasa.gov Thu Jan 6 17:25:32 2000 Received: from mailhub.dfrc.nasa.gov (mailhub.dfrc.nasa.gov [130.134.81.12]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id RAA16599 for ; Thu, 6 Jan 2000 17:25:31 +0100 (CET) (envelope-from maine@altair.dfrc.nasa.gov) Received: from mail.dfrc.nasa.gov by mailhub.dfrc.nasa.gov with ESMTP; Thu, 6 Jan 2000 08:15:06 -0800 Received: from altair.dfrc.nasa.gov ([130.134.129.8]) by mail.dfrc.nasa.gov (Post.Office MTA v3.5.3 release 223 ID# 35-62055U1500L100S0V35) with ESMTP id gov; Thu, 6 Jan 2000 08:18:38 -0800 Received: (from maine@localhost) by altair.dfrc.nasa.gov (8.9.3/8.9.3) id IAA03251; Thu, 6 Jan 2000 08:18:38 -0800 From: Richard Maine MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14452.49246.542492.898544@altair.dfrc.nasa.gov> Date: Thu, 6 Jan 2000 08:18:38 -0800 (PST) To: "Kruyt, E. W." Cc: SC22WG5@dkuug.dk Subject: (SC22WG5.1693) Some discussion points/wishes In-Reply-To: <200001061323.OAA08630@dkuug.dk> References: <200001061323.OAA08630@dkuug.dk> X-Mailer: VM 6.72 under 21.1 (patch 7) "Biscayne" XEmacs Lucid Kruyt, E. W. writes: > I run into some inconsistencies and limitations of Fortran 95 which I would > like to suggest to change/improve in Fortran 2000. Its basically about 3 years late for new f2k proposals unless they are either so critical that it is worth schedule disruption or so trivial that they don't require measurable effort. (And note that even very trivial things have a way of disrupting integration work if there are many of the "trivial" things; this has been demonstrated). > 1. In free source form one or more blanks shall be used to separate adjacent > keywords except in the following cases. > I suggest to add ELSE WHERE because END WHERE and ELSE IF are also in that > list. I've no strong opinion on this. > 2. It would be convenient to allow the name of an assumed size array in a > data transfer input list. Why is this disallowed? Because the compiler has no idea how big the array is. The standard is written in such a way that compilers need not pass information about the actual size of an assumed-size array. And indeed many compilers do not pass the size. Assumed-size whole arrays are thus disallowed in all contexts where there actual size would have to be known by the compiler. I/O lists are one such place. Changing this would be radical (and most unlikely to pass, in my opinion, even without the question of schedule). > 3. It would be convenient to be able to specify ADVANCE='NO' also for list > directed I/O. Why was this excluded? Probably because it would not actually achieve what you think unless there were also other changes. A compiler is allowed to end lines largely at its discretion (as long as its not in the middle of some values) in list-directed output. Thus, unless there were changes in that rule, it would be perfectly standard-conforming for a compiler to effectively ignore advance='no' on list-directed output. The compiler could claim that it did one of the discretionary line ends. Presumably this could be fixed. But it would need more than just saying that advance='no' was allowed. Too much (in my opinion) for a change this late. > 4. DELIM= can only be specified in an OPEN statement. I should like to be > able to specify it (also) in the control info list of a READ statement. I'm not sure why this is. Your request seems reasonable to me. Indeed some changes like this were made in the current f2k draft, but I don't recall whether DELIM was amongst them. The changes I recall related to specifiers added by some of the new internationalization stuff, but DELIM does seem to share many of the same issues. I think I could agree (unless someone recalls something I forgot about) with making DELIM like the other specifiers that can be specified either in OPEN or READ/WRITE. Seems like a plausible consistency fixup for integration. > 5. Why is it not possible to specify UNIT=* in an OPEN statement? This to > specify DELIM= for standard input as you cannot specify it in the > control-info list of a READ (see previous point). You can't specify unit=* in an OPEN because it is ambiguous. There are separate * units for input and output; it would not be clear which one was intended in an OPEN. This problem is, however addressed by a separate change already in the f2k draft. That change allows you to get unit numbers that corresponds to the two uses of *. Thus you can use those unit numbers in the OPEN. -- Richard Maine maine@altair.dfrc.nasa.gov