From jkr@jkr.cc.rl.ac.uk Wed May 2 18:40:18 2001 Received: from nameserv.rl.ac.uk (nameserv.rl.ac.uk [130.246.135.129]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id SAA61405 for ; Wed, 2 May 2001 18:40:18 +0200 (CEST) (envelope-from jkr@jkr.cc.rl.ac.uk) Received: from jkr.cc.rl.ac.uk (jkr.cc.rl.ac.uk [130.246.8.20]) by nameserv.rl.ac.uk (8.8.8/8.8.8) with ESMTP id RAA31512 for ; Wed, 2 May 2001 17:40:33 +0100 Received: (from jkr@localhost) by jkr.cc.rl.ac.uk (8.8.8+Sun/8.8.8) id RAA02229 for SC22WG5@dkuug.dk; Wed, 2 May 2001 17:42:39 +0100 (BST) Date: Wed, 2 May 2001 17:42:39 +0100 (BST) From: John Reid Message-Id: <200105021642.RAA02229@jkr.cc.rl.ac.uk> To: SC22WG5@dkuug.dk Subject: Interp F90/190 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" WG5, Here is a revised draft response for interp. F90/190. Comments, please, preferably to me in private, before I send this to J3. John Reid. J3/01-xxx Date: 2 May 2001 To: J3 From: John Reid Subject: Interpretation F90/000190 (Subobjects of constants in a DATA statement) Here is a new draft response. I append the present draft and the comments on it that were made with the J3 ballot in 1995. I have added words to the question to make it clear that it is asking a question of the Fortran 90 standard. The answer is entirely new and says that this question is not relevant to the Fortran 95 standard. NUMBER: F90/000190 TITLE: Subobjects of constants in a DATA statement KEYWORDS: DATA stmt, constant DEFECT TYPE: Interpretation STATUS: J3 consideration in progress QUESTION: Consider the following syntax rules from Section 5.2.9 of the Fortran 90 standard: R532 is [*] R533 is ... R534 is and the following constraint Constraint: A of a must involve as primaries only constants or DO variables of the containing s, and each operation must be intrinsic. In all cases, the rules reduce to "constant". The definition of "constant" is provided by R305: R305 is or R307 is The above two rules seem to indicate that if an identifier appears where "constant" is allowed in the DATA statement rules cited above, the identifier must be a name; that is, it can not be the subobject of a named constant. Is this analysis correct? ANSWER: It is not correct for the Fortran 95 standard, which permits subobjects of a named constants in these situations. The corresponding rules (page 62) are Constraint: A of a shall involve as primaries only constants, subobjects of constant, or DO variables of the containing s, and each operation shall be intrinsic. R539 is or R540 is or ... EDITS: None SUBMITTED BY: Larry Rolison HISTORY: 94-302 m131 submitted, with proposed response 94-360 m131 alternate answer proposed, failed 7-7 94-302 m131 original answer, approved 14-2 95-034 m132 X3J3 ballot failed 15-5 ----------------------------------------------------------------------------- Old answer ANSWER: Yes, your analysis is correct. A , a , and a constant appearing in a of a DATA implied-DO can be a name (of a named constant) but not a subobject designator. Discussion: There is no intent in the standard to extend the above rules over what was provided in the FORTRAN 77 standard. So, for example, the following program fragment is not standard conforming: INTEGER, PARAMETER :: PARR(3) = (/ 1, 2, 3 /) INTEGER :: ARRAY(3) DATA (ARRAY(I), I = PARR(1), 3) / PARR(1), PARR(2)*PARR(3) / ------------------------------------------------------------------------------- Ballot comments 000190 Subobjects of constants in a DATA statement Vote = 15 (2) - 5 190 N Bierman It seems rather suboptimal to me to have this interp response *and* the f95 extension. Given that we've chosen to add it to the standard, I'd much prefer that we fix this *now*. Otherwise we make compiler writers do extra work, and we have to educate users twice. 190 N Dedo I agree with Larry Rolison and Keith Bierman. Fortran 95 will allow subobjects in constant expressions so we should allow them right now. 190 Y Hirchert Although I appreciate Larry Rolison's concerns about the inconsistency in the requirements of a Fortran 90 processor and those of a Fortran 95 processor, there is still a difference between the behaviors we can impose retroactively and those we can introduce in a new revision. This case illustrates that dividing line. 190 Y Levine Rolison's argument is also compelling: here today, gone tomorrow. This all becomes moot very soon, one would hope. 190 N North See comments by L. Rolison. 190 N Rolison I must vote NO on this response even though it is the one I want because the committee has, in my humble opinion, done both compiler writers and users a disservice due to the combination of votes at Meeting 131 regarding this Interp. The committee voted to say that allowing subobjects in DATA statement constant contexts was NOT allowed in Fortran 90 and then turned around immediately and allowed them in Fortran 95. This is ridiculous. I venture to say that all vendors of Fortran compilers are trying their best to keep up with changes in the standard and it is just plain silly to tell vendors to issue an error message now but in a few months delete the error message. This is a waste of programmer time and will only cause users grief because no doubt at least some vendors are going to extend it now anyway knowing full well what's going to happen in Fortran 95. So in spite of my continuing disagreement with the majority opinion on this topic, if we're going to allow the subobjects in F95, let's just use the original answer to the Interp which allows them now. 190 N Whitlock I agree with Larry Rolison's NO vote. ------------------------------------------------------------------