From owner-sc22wg5@dkuug.dk Tue Jul 29 16:41:27 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h6TEfR7f059079 for sc22wg5-domo; Tue, 29 Jul 2003 16:41:27 +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 out8.mx.nwbl.wi.voyager.net (out8.mx.nwbl.wi.voyager.net [169.207.3.117]) by dkuug.dk (8.12.8p1/8.9.2) with ESMTP id h6TEfKEc059073 for ; Tue, 29 Jul 2003 16:41:23 +0200 (CEST) (envelope-from Craig_Dedo@execpc.com) Received: from execpc.com (d52.as17.nwbl1.wi.voyager.net [169.207.89.180]) by out8.mx.nwbl.wi.voyager.net (Postfix) with ESMTP id CC9D23C13E; Tue, 29 Jul 2003 09:41:10 -0500 (CDT) Message-ID: <3F268789.9030107@execpc.com> Date: Tue, 29 Jul 2003 09:41:13 -0500 From: Craig Dedo Reply-To: Craig Dedo Organization: Elmbrook Computer Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stan Whitlock Cc: x3j3 , WG5 , John_Reid Subject: Re: (SC22WG5.2903) Attn WG5: F95 interp letter ballot #7 results References: <200307281337.h6SDbM7N050919@dkuug.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-sc22wg5@dkuug.dk Precedence: bulk Dear Stan: It appears that you did not count Kurt Hirchert's vote on the interpretations ballot. He did not copy you separately; he only sent his ballot to the J3 Mailing List and his ballot got stuck inside the mail server until this morning. Kurt got his ballot in on time so you may wish to add Kurt's votes to the results and amend the report to J3 and WG5 accordingly. Whitlock, Stan wrote: >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 > > > > > > -- Sincerely, Craig T. Dedo 17130 W. Burleigh Place E-mail: Craig_Dedo@execpc.com Brookfield, WI 53005-2759 Voice Phone: (262) 783-5869 USA Fax Phone: (262) 783-5928 "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin (1759)