J3/03-218 Date: 04 August 2003 To: J3 From: Matthijs van Waveren Subject: Processing of items from the J3 letter ballot Re: WG5/N1561 ISO/IEC JTC1/SC22/WG5 N1561 Processing of items from the J3 letter ballot 1. Introduction This paper contains recommendations from an interpretation subgroup for processing by WG5 of the items that passeed the recent J3 letter ballot (N1554). Interpretations 000099, 000100, JP-17 are discussed in section 2. Interpretation 000101 is discussed in section 3, and interpretation JP-24 is discussed in section 4. 2. Uncontroversial Items The following items passed the J3 letter ballot nem con. Subgroup examined these and recommended that they be approved by WG5. 000099 STAT= variable requirements in ALLOCATE 000100 TARGET attribute and structure components JP-17 Multiple occurrence of namelist group object in namelist group 3. Interpretation 000101 Interpretation 000101 also passed the letter ballot, but with two negative votes and comments. The interpretation and the comments are reproduced below. The WG5 interpretation subgroup recommends that this interpretation be approved as is. Generic interfaces like the one appearing in the example code in interpretation 101 are non-conforming, because the example in the interpretation shows that the resolution is ambiguous. The intention of the rules in the standard is to ensure that all calls using a generic interface be unambiguous. ======================INTERPRETATION 101==================================== NUMBER: 000101 TITLE: Generic resolution KEYWORDS: generic, argument DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider: INTERFACE g SUBROUTINE s1(p) INTERFACE SUBROUTINE p END END INTERFACE END SUBROUTINE s2(p) INTERFACE REAL FUNCTION p() END END INTERFACE END END INTERFACE EXTERNAL procedure CALL g(procedure) The generic interface block seems to satisfy the requirements of 14.1.2.3, in that s2 has more arguments of type REAL than has s1, but since the data type of "procedure" is not known (it may be a default REAL function, or it may be a subroutine), the CALL appears to be ambiguous. Is this code standard-conforming? ANSWER: No, this was not intended to be standard-conforming. An edit is supplied to correct this oversight. EDITS: [277:21-23] Change "arguments" to "data objects" three times. SUBMITTED BY: Malcolm Cohen. HISTORY: 02-251 m162 Submitted, passed by J3 meeting 03-xxx m165 Pending resolution of J3 letter ballot =============================COMMENTS==================================== * Rob James' NO vote on interpretation 000101: The proposed edit for this interpretation clearly makes the code in question non-conforming, but I believe it goes too far. The edit also makes the following code non-conforming, although the intent of the code is obvious: INTERFACE g SUBROUTINE s1(p) INTERFACE SUBROUTINE p END SUBROUTINE END INTERFACE END SUBROUTINE SUBROUTINE s2(p) INTERFACE REAL FUNCTION p() END FUNCTION END INTERFACE END SUBROUTINE END INTERFACE INTERFACE SUBROUTINE procedure END SUBROUTINE END INTERFACE CALL g(procedure) END I believe that this code should be standard-conforming. Perhaps an edit to clarify what it means for a reference to be "consistent with" a specific interface (in section 14.1.2.4.1) would be more appropriate, rather than a blanket restriction on generic interfaces like the one appearing in the code in question. * Craig Dedo's No vote on Interpretation 101: I agree with Rob James. Let's see if there is a fairly painless way to implement his idea. If, after due consideration, it appears that his idea will be unduly complicated, I will change my vote to "Yes". ============================================================================== 4. Interpretation JP-24 The WG5 interpretation subgroup requests J3 to reconsider the edit given in interpretation JP-24. We give below an example code that would be allowed by the new bnf as a single construct, but should not be. do 10 i=1,5 ! outer do 20 j=1,5 ! inner ... 10 continue ! shared The edit that would disallow above-mentioned code as a single construct would read as follows: [127:29.5] Replace "" by " and ". ===========================INTERPRETATION JP-24================================ NUMBER: JP-24 TITLE: The bnf term shared-term-do-construct KEYWORDS: DO, BNF DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: JP-24) In 8.1.4.2, second constraint below R833 states that: "The do-term-shared-stmt shall be identified with a label and all of the label-do-stmts of the shared-term-do-construct shall refer to the same label." This implies a label-do-stmts of the outer-most outer-shared- do-construct will permit not to refer to the same label, because shared-term-do-construct does not include outer-most outer- shared-do-construct. So the term "shared-term-do-construct" should be changed to "inner-share-do-construct and outer-shared-do-construct." DISCUSSION: There is a typographical error in the question - "8.1.4.2" should read "8.1.4.1.2". The following amplification of the question was provided at the August 2000 WG5 meeting: The present BNF does not preclude the following as a single construct: do 10 i=1,5 ! outer do 20 j=1,5 ! outer do 20 k=1,5 ! outer do 20 l=1,5 ! inner ... 20 continue ! shared ANSWER: Agreed. There is a minor change in the suggested replacement text. EDIT: [127:29.5] Replace "" by "". {The intention is to alter the second line of the second constraint following R833. The line numbering is awry in the F95 copy being used.} SUBMITTED BY: Japan HISTORY: 99-208 m150 Submitted 99-221 m150 Classified as Fortran 95 interpretation WG5-N1411 Aug-2000 Draft answer 02-131r1 m160 Passed unanimously by J3 meeting 03-xxx m165 Passed by J3 letter ballot WG5-N1561 Request from WG5 to reconsider