From owner-sc22wg5@dkuug.dk Wed Jan 8 20:45:12 2003 Received: (from majordom@localhost) by dkuug.dk (8.9.2/8.9.2) id UAA35095 for sc22wg5-domo; Wed, 8 Jan 2003 20:45:12 +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 math.jpl.nasa.gov (math.jpl.nasa.gov [137.79.7.57]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id UAA35090 for ; Wed, 8 Jan 2003 20:45:10 +0100 (CET) (envelope-from vsnyder@math.jpl.nasa.gov) Received: from math.jpl.nasa.gov (localhost.localdomain [127.0.0.1]) by math.jpl.nasa.gov (8.12.5/8.12.5) with ESMTP id h08JjKOe009386 for ; Wed, 8 Jan 2003 11:45:20 -0800 Received: from math.jpl.nasa.gov (vsnyder@localhost) by math.jpl.nasa.gov (8.12.5/8.12.5/Submit) with ESMTP id h08JjFxO009382 for ; Wed, 8 Jan 2003 11:45:19 -0800 Message-Id: <200301081945.h08JjFxO009382@math.jpl.nasa.gov> X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: inbox To: SC22WG5@dkuug.dk Subject: Re: (SC22WG5.2664) A partial comment about "Status of Repository items" In-Reply-To: Your message of "Wed, 08 Jan 2003 09:15:03 GMT." <200301080913.KAA26654@dkuug.dk> Mime-Version: 1.0 Content-Type: text/plain Date: Wed, 08 Jan 2003 11:45:15 -0800 From: Van Snyder Sender: owner-sc22wg5@dkuug.dk Precedence: bulk Concerning the relation between the post-1995 wishlist and the next standard, John Reid wrote, in part: > >> These are the items that I believe are adopted in the present > >> draft Fortran 2000, sometimes not in the way that was suggested: and Bernard Pichon wrote: > >> 93 New keywords READ_EOR, READ_EOF, WRITE_EOR (?), WRITE_EOF (?) > >> in INQUIRE statements > see Sect. 9.10.4 and 13.8.3.2 > > In Sect. 9.10.4 (3) and (4), I suggest to replace > "With a processor-dependent negative integer value of the constant ... " > by > "With the processor-dependent negative integer value of the constant ... " > ^^^ The wording Pichon advocates is the present wording for (3) but not for (4). I wonder why we did that? At the last J3 meeting, Cray and IBM noted that they provide several values for the IOSTAT variable for the end-of-file case, to indicate different reasons for noticing the end of file, and similarly for the end-of-record case. 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. Presumably, one would use if ( any(myStatus == iostat_eof) ) then... in this case. Also presumably, this is what would be inside of a function that returned .TRUE. if its argument represented an end-of- file condition. The paper isn't at the J3 repository yet, but there's nothing secret about it. I just put off sending my papers to the librarian until two weeks before the meeting, because I seem inevitably to want to make some tiny last-minute adjustment -- such as changing "a" to "the" at 216:14. If anybody wants to see a draft, I'm happy to send it. In the constant array case, 216:12 becomes (3) With the processor-dependent negative integer value of one of the elements of the default integer rank-one array constant IOSTAT_END (13.8.3.2.1) if an end-of-file condition occurs and no error occurs, or This is a bit redundant, given that 13.8.3.2.1 will say most of this, so it could be reduced to (3) With the processor-dependent value of one of the elements of the array constant IOSTAT_END (13.8.3.2.1) if an end-of-file condition occurs and no error occurs, or It may also be desirable to put "processor-dependent" in 13.8.3.2 instead of 9.4.10. -- Van Snyder | What fraction of Americans believe vsnyder@math.jpl.nasa.gov | Wrestling is real and NASA is fake? Any alleged opinions are my own and have not been approved or disapproved by JPL, CalTech, NASA, Sean O'Keefe, George Bush, the Pope, or anybody else.