From owner-sc22wg5@dkuug.dk Mon Jul 28 15:37:21 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h6SDbLtj050908 for sc22wg5-domo; Mon, 28 Jul 2003 15:37:21 +0200 (CEST) (envelope-from owner-sc22wg5@dkuug.dk) X-Authentication-Warning: ptah.dkuug.dk: majordom set sender to owner-sc22wg5@dkuug.dk using -f Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by dkuug.dk (8.12.8p1/8.9.2) with ESMTP id h6SDb5Ec050903 for ; Mon, 28 Jul 2003 15:37:13 +0200 (CEST) (envelope-from stan.whitlock@intel.com) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h6SDVij06745 for ; Mon, 28 Jul 2003 13:31:44 GMT Received: from fmsmsxv040-1.fm.intel.com (fmsmsxv040-1.fm.intel.com [132.233.48.108]) by petasus.fm.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h6SDTe418344 for ; Mon, 28 Jul 2003 13:29:40 GMT Received: from FMSMSX016.fm.intel.com ([132.233.42.195]) by fmsmsxv040-1.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003072806360711603 ; Mon, 28 Jul 2003 06:36:07 -0700 Received: by fmsmsx016.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jul 2003 06:36:56 -0700 Message-ID: <88E10B707C51824DA13AA135A402DF47079E2B@hdsmsx403.hd.intel.com> From: "Whitlock, Stan" To: x3j3 , WG5 Cc: John_Reid , "Whitlock, Stan" Subject: Attn WG5: F95 interp letter ballot #7 results Date: Mon, 28 Jul 2003 06:36:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) content-class: urn:content-classes:message Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-sc22wg5@dkuug.dk Precedence: bulk Mallory - please give this a J3 paper number and put it on the server for meeting #165. To WG5 meeting in Dresden - please consider the results of this J3 letter ballot on F95 interps. ----------------------------------------------------------------- To: J3 and WG5 03-xxx From: /interp/Stan Whitlock Subj: F95 interp letter ballot #7 results Here are the results of the J3 letter ballot #7 on F95 interps. 5 Fortran 95 interpretations are currently "passed by J3 meeting" in 02-006Ar1.txt. This was the letter ballot phase to go from "passed by J3 meeting" to "passed by J3 letter ballot". 12 of 14 J3 members voted {no ballot received from Hirchert or Meadows}. The following Fortran 95 interpretations were balloted: Result Yes No Number Title Passed 12 0 000099 STAT= variable requirements in ALLOCATE Passed 12 0 000100 TARGET attribute and structure components Pending 10 2 000101 Generic resolution Passed 12 2 JP-17 Multiple occurrence of namelist group object in namelist group Passed 12 2 JP-24 The bnf term shared-term-do-construct 4 interps pass the letter ballot {99, 100, JP-17, JP-24} - these can be accepted by WG5 and become "Passed by WG5 ballot". 1 interp is still pending, based on 2 no votes - /interp would appreciate any input WG5 would like to give on this interp: * 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". The text of these interpretetions is attached. Each interpretation starts with a row of "-"s. Thanks /Stan ---------------------------------------------------------------------- NUMBER: 000099 TITLE: STAT= variable requirements in ALLOCATE KEYWORDS: ALLOCATE, STAT= DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: [79:40-41] says "The shall not appear in a bound in the same ALLOCATE statement." This requirement appears, on the face of it, to apply to the syntax, not to whichever actual variable is identified by the syntax. Question 1: Given INTEGER :: A(10) = (/ (i,i=1,10) /) POINTER P(:) READ *,I,J ALLOCATE(P(A(I)),STAT=A(J)) Is the ALLOCATE standard-conforming, or does it depend on the relative values of I and J? From the quoted text, it would appear that it is always conforming, even when I==J. Question 2: Similarly, given: EQUIVALENCE(I,J) POINTER P(:) I = 5 ALLOCATE(P(I),STAT=J) is the ALLOCATE conforming? Question 3: Similarly, given: POINTER P(:) INTRINSIC DIGITS I = 5 ALLOCATE(P(DIGITS(I)),STAT=I) is the ALLOCATE conforming? From the quoted text, it would appear not to be conforming, despite the non-dependence of the array bound on the value of the STAT= variable. ANSWER: The intent was that the restriction should apply to the actual variable being used for the STAT= variable, not to the syntax. Thus, (1) The ALLOCATE statement is only standard-conforming if I and J are not equal. (2) The ALLOCATE statement is not standard-conforming. (3) The ALLOCATE statement is standard-conforming. Edits to the standard are supplied to clarify this. EDITS: [79:40-41] Delete "The ... statement." [80:6] Append to paragraph "No array bound in an ALLOCATE statement shall depend on the value of the ." SUBMITTED BY: Malcolm Cohen. HISTORY: 02-232 m162 Submitted 02-232r1 m162 Revised, passed by J3 meeting 03-xxx m165 Passed by J3 letter ballot ---------------------------------------------------------------------- NUMBER: 000100 TITLE: TARGET attribute and structure components KEYWORDS: TARGET, POINTER DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: The standard says ([110:43-44]), of R737 , "Constraint: The shall have the TARGET attribute or be a subobject of an object with the TARGET attribute, or it shall have the POINTER attribute." It also says ([75:22-23]), of structure components "A structure component has the ... TARGET ... attribute if the parent object has the attribute." The <> is defined ([75:16]) as "the data object whose name is the leftmost part name". Consider: TYPE t REAL x END TYPE TYPE(t),POINTER :: p REAL,POINTER :: q ALLOCATE(p) q => p%x Q1. Is this standard-conforming? If the answer to Q1 is Yes, this still appears to leave unspecified the case of A%B%C where A does not have the TARGET attribute and B has the POINTER attribute. The parent object of A%B%C is just A, and A does not have the TARGET attribute. Therefore the conclusion is that A%B%C does not have the TARGET attribute. Note: Although the standard says that "Allocation of a pointer creates an object that implicitly has the TARGET attribute" [81:47-48], is it not entirely sure that this shows that A%B%C has the attribute for two reasons: (1) Allocation is not the only way of establishing pointer associations. (2) According to the quoted text, whether A%B refers to an object with the TARGET attribute is immaterial; the only question is whether A itself has the TARGET attribute. Q2. Does this A%B%C have the TARGET attribute? Note: the following example may be relevant: TYPE t TYPE(t2),POINTER :: p END TYPE TYPE t2 REAL x END TYPE TYPE(t) v TYPE(t2),POINTER :: z REAL,POINTER :: q ALLOCATE(v%p) ! ! (a) ! z => v%p q => z%x ! ! (b) ! q => v%p%x The pointer assignments following (a) are clearly valid: the first assigns one pointer to another, and if the answer to Q1 is Yes, the second one follows from that. But the (a) statements have the same effect as the (b) statement, so it would be inconsistent to disallow (b). Q3. Apparently, substrings never have the INTENT, TARGET or PARAMETER attribute. Is this a deliberate omission? ANSWER: Q1: Yes. P points to an object with the TARGET attribute, and X is a subobject of this object. Therefore, "Q => P%X" is conforming. Q2: The standard leaves this case unspecified, but the intent is that any part of an object with the TARGET attribute should itself have the attribute. An edit is supplied to remedy this omission in the standard. Q3: No, this omission was inadvertant. An edit is supplied to fix this. EDITS: [74:33] Append to paragraph "A substring has the INTENT, TARGET, or PARAMETER attribute if its parent has the attribute, but it never has the POINTER attribute." {Fix omission. Text parallels that for array elements and sections.} [75:22] Delete ", TARGET,". [75:23] After "." insert "A structure component has the TARGET attribute if the parent object has the attribute or if any except the rightmost has the POINTER attribute." [110:43-44] Delete "be a subobject of an object with the TARGET attribute or it shall have". {Now that propagation of TARGET is fixed, we don't need the weasel words.} SUBMITTED BY: Malcolm Cohen. HISTORY: 02-233 m162 Submitted 02-233r1 m162 Revised, passed by J3 meeting 03-xxx m165 Passed by J3 letter ballot ---------------------------------------------------------------------- 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 resoilution of J3 letter ballot ---------------------------------------------------------------------- NUMBER: JP-17 TITLE: Multiple occurrence of namelist group object in namelist group KEYWORDS: NAMELIST DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot QUESTION: JP-17) 5.4 3rd paragraph after R545 and constraints states that: "A namelist group object may be a member of more than one namelist group." Can a namelist group object occur more than once in one namelist group? Is the following NAMELIST statement standard conforming? NAMELIST /NLIST/A,B,A ANSWER: Yes. DISCUSSION: Sections 5.4 "NAMELIST Statement" and 10.9 "Namelist Formatting" in Fortran 95 do not disallow multiple occurrences of a namelist group object in a namelist group. This is also true in Fortran 90. Therefore the multiple occurrences are standard conforming. EDITS: None. SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. WG5-N1411 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Failed J3 letter ballot 01-300 m158 Passed by J3 meeting 01-380 m158 Passed by J3 letter ballot WG5/N1470 Failed WG5 ballot 02-130 m160 Change "no" to "yes": Passed by J3 meeting 03-xxx m165 Passed by J3 letter ballot ---------------------------------------------------------------------- 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