From owner-sc22wg5@dkuug.dk Wed Jan 8 23:18:28 2003 Received: (from majordom@localhost) by dkuug.dk (8.9.2/8.9.2) id XAA37329 for sc22wg5-domo; Wed, 8 Jan 2003 23:18:28 +0100 (CET) (envelope-from owner-sc22wg5@dkuug.dk) X-Authentication-Warning: ptah.dkuug.dk: majordom set sender to owner-sc22wg5@dkuug.dk using -f Received: from mail1.cray.com (mail1.cray.com [136.162.0.111]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id XAA37324 for ; Wed, 8 Jan 2003 23:18:26 +0100 (CET) (envelope-from longb@cray.com) Received: from relayb.mw.cray.com (relayb.us.cray.com [192.168.252.110]) by mail1.cray.com (8.12.3/8.12.3/gw-1.14) with ESMTP id h08MANJ6020353; Wed, 8 Jan 2003 16:10:23 -0600 (CST) Received: from saffron.us.cray.com (saffron.mw.cray.com [172.31.27.14]) by relayb.mw.cray.com (8.12.3/8.12.3/hub-1.14) with ESMTP id h08MAMM1010307; Wed, 8 Jan 2003 16:10:22 -0600 (CST) Received: from cray.com (mh-dhcp-172-31-20-79 [172.31.20.79]) by saffron.us.cray.com (8.8.8/Cray-server-1.6-nhsmod011017) with ESMTP id QAA14318036; Wed, 8 Jan 2003 16:10:22 -0600 (CST) Message-ID: <3E1CA2DF.20809@cray.com> Date: Wed, 08 Jan 2003 16:14:55 -0600 From: Bill Long Reply-To: longb@cray.com Organization: Cray Inc. User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Richard Maine CC: SC22WG5@dkuug.dk Subject: Re: (SC22WG5.2667) A partial comment about "Status of Repository items" References: <200301080913.KAA26654@dkuug.dk> <200301081945.UAA35106@dkuug.dk> <200301082107.WAA36342@dkuug.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Cray-VirusStatus: clean Sender: owner-sc22wg5@dkuug.dk Precedence: bulk Richard Maine wrote: >Van Snyder writes: > > > J3 agreed to recommend that the IOSTAT_END and > > IOSTAT_EOR constants should be functions. I've written a paper 03-103 > > that provides the edits to do that, and parallel edits to provide those > > constants as arrays. The wording using constant arrays is cleaner. > >The wording may be cleaner, but the usage is not. I find it noticably >simpler to write > > if (is_eof(my_status)) then > I agree with Richard that the function form is more user friendly. For implementations with a single value, the function is trivial to optimize away. > >than > > > if ( any(myStatus == iostat_eof) ) then... > >Note that the array suggestion *WAS* mentioned at the meeting and >wasn't what passed. > >Note also my comment from my posting of a minute ago - although >the issue of vendors who return multiple values was mentioned as >the justification of this change, the vote taken did not include >a suggestion to delete the requirement for a single value. > > From what I see, this requirement is implied by the phrase "from THE end-of-file value" (caps added) in [146:28] of f95. I guess this one word is enough. Elsewhere we tend to refer to "a" constant. Is changing "the" to "an" in [146:28] the only change that would be required to allow multiple values? I'm not necessarily advocating that we make the change. I'm just curious about where the requirement is stated in the standard. Cheers, Bill >There is some evidence that this is partly because many people >didn't realize that there was such a requirement. Perhaps there >would be a majority in favor of deleting the requirement. But I >do *NOT* think it appropriate to assume the outcome of such a vote. >Providing a function instead of a constant is not a change >incompatable with f95 (since f95 has no such thing). The issue >of incompatability might matter to some people, so that it is >quite possible that you would get a different outcome if there >actually were a vote to make an incompatable change. > >If the majority does want to make an incompatable change, I think >that is an important enough issue to be voted on explicitly in >such terms - not slipped in the "back door" as a consequence of >a vote that failed to mention that it was such a change. And if >people don't think this would be an change incompatable with f95, >then we need and f95 interp, because I think it is. > >The reason I bring this up in particular response to the constant >array suggestion is that a constant array makes it all but explicit >that multiple values must be allowed (even though I maintain that it >still contradicts other words in the draft). It is, after all, really >nonsensical to require that it be an array of size 1. The function >doesn't necessarily imply multiple values, however. It is a plausible >style preference to like the function form instead of the constant >form, even for the scalar case. (It isn't my personal style >preference, but it is a plausible one). > > > -- Bill Long longb@cray.com Fortran Technical Support voice: 651-605-9024 Cray Inc. fax: 651-605-9142 1340 Mendota Heights Rd., Mendota Heights, MN, 55120