J3/07-272 Date: 4-Aug-2007 To: J3 Members From: /interp/Stan Whitlock Subj: Results of the J3 interp letter ballot #13 Here are the results of J3 letter ballot #13 on Fortran interpretations: the letter ballot officially closes 17-Aug-2007; however, all of the members of J3 cast their ballots before 6-Aug so the results will be processed at meeting #181. The ballot is in J3 paper 07-250r1 for meeting #181. If I have transcribed a vote or a comment incorrectly, please let me know. J3 rep F03 F03 F03 F03 F03 F03 F03 F03 F03 48 49 50 51 86 87 88 89 90 Dick Hendrickson C C C Y C C Y Y Y Michael Ingrassia Y Y C Y Y Y Y Y Y Shivarama Kokrady (1) Y Y C Y Y Y Y Y Y Bill Long C C C Y C C Y Y Y Jeanne Martin Y Y C Y Y Y Y Y Y Dan Nagle Y Y C Y Y Y Y Y Y Craig Rasmussen Y Y C Y Y Y Y Y Y Van Snyder Y Y C Y Y Y Y Y Y Toon Moene (2) Y Y C Y Y Y Y Y Y Stan Whitlock Y Y C Y Y Y Y Y Y Jim Xia (3) Y Y Y N N Y C Y N where Y means "yes" C "yes with comment" N "no with comment" (1) Shivarama is HP's representative, replacing Rich Bleikamp (2) Toon is the alternate for Matthijs van Waveren (3) Jim is IBM's representative, replacing Rob James The comments for each interp are attached below in the same order as the table above. The summary of DRAFT results is as follows: P = passed C = passed as amended N = needs further consideration F03 F03 F03 F03 F03 F03 F03 F03 F03 48 49 50 51 86 87 88 89 90 N C C N C N C P N The interps marked "C" pass with some minor fixes, as noted below. The interps marked "N" will be reconsidered at J3 meeting #181 by the /interp committee who will decide if the status becomes "withdraw for more work", "passed as amended", or "passed as printed". The edited interps in their final form (except for the J3 number for this paper) for F03/0049 F03/0050 F03/0086 F03/0088 F03/0089 are attached for use at meeting #181. /Stan ********************************************************************** F03/0048 Control edit descriptors in UDDTIO Dick Hendrickson's YES on F03/0048: I agree with Bill Long's suggested addition to clause 10 Add this paragraph at [236:2+]: "The left tab limit for a child data transfer statement is the file position of the parent data transfer statement at the time that the user-defined derived-type input/output procedure was invoked." on the grounds that the stuff related to Tx edit descriptors really belongs in 10.7.1.1. Bill Long's YES comment on F03/0048: In looking at the test resulting from the edits, it seems like it would be better to delete paragraph [202:36-203:2] and instead add this paragraph at [236:2+]: "The left tab limit for a child data transfer statement is the file position of the parent data transfer statement at the time that the user-defined derived-type input/output procedure was invoked." on the grounds that the stuff related to Tx edit descriptors really belongs in 10.7.1.1. Given that the concept of left tab limit already includes most of what is in the paragraph at [202:32-34], one might consider deleting that paragraph as redundant. Conclusion on F03/0048: Has not yet passed J3 letter ballot #13 - /interp will consider the above comment from Bill Long at meeting #181 ---------------------------------------------------------------------- F03/0049 Separators in list-directed output involving UDDTIO Dick Hendrickson's YES comment on F03/0049: I agree with Bill Long's comment In the edit, "list directed" should be hyphenated, and we have changed "I/O" to "input/output" elsewhere in the standard, so should here as well. Bill Long's YES comment on F03/0049: In the edit, "list directed" should be hyphenated, and, I believe, we have changed "I/O" to "input/output" elsewhere in the standard, so should here as well. Conclusion on F03/0049: Passed J3 letter ballot #13 with the above change in Bill Long's ballot ---------------------------------------------------------------------- F03/0050 Questions about internal files Dick Hendrickson's YES comment on F03/0050: I agree with Van et. al.'s comments Michael Ingrassia's YES comment on F03/0050: with Van's changes Shivaram Kokrady's YES comment on F03/0050: with Van's changes Bill Long's YES comment for F03/0050: Concurring with Van, in the edit, "specified" -> "specifies", and "internal unit" -> "internal file". Jeanne Martin's YES comment on F03/0050: Yes, with Van's changes. Toon Moene's YES comment on F03/0050: I agree with Van's comment. Dan Nagle's YES comment on F03/0050: With the comment Van made, namely In both paragraphs of the proposed edits, "specified" should be "specifies" and "internal unit" should be "internal file". Craig Rasmussen's YES comment on F03/0050: Yes, with Van's changes. Van Snyder's YES comment on F03/0050: In both paragraphs of the proposed edits, "specified" should be "specifies" and "internal unit" should be "internal file". Stan Whitlock's YES comment on F03/0050: I agree with Van's vote: In both paragraphs of the proposed edits, "specified" should be "specifies" and "internal unit" should be "internal file". Malcolm Cohen's comment on F03/0050: Furthermore, "referenced or defined" should be "referenced, defined, or become undefined". And the last paragraph should have "or become undefined" after "defined". Conclusion on F03/0050: Passed J3 letter ballot #13 with the above change in Van Snyder's ballot and Malcolm Cohen's comment. ---------------------------------------------------------------------- F03/0051 Repeat specifiers and UDDTIO Jim Xia's NO vote on F03/0051: While I agree with the spirit of the interp, the edit seems to have a problem. Consider the text in the edit marked between *** below: "When the first value of an constant is transferred to a list item by a list-directed input statement, that input statement shall transfer all values of that constant ***to list items*** before causing any child input statement to be invoked. If that list-directed input statement is itself a child input statement, it shall transfer all values of that constant ***to list items*** before terminating." There may not be enough list items to transfer all values to. I think the input statement should transfer as many (up to ) values as are available list items and then ignore (throw away) the rest. For example, for the program in the interp document: The first child input statement encounters 2*3. It will transfer a number 3 to dtv%i. There are no more list items to transfer the second 3 to, so I believe it should skip the second number 3. Here is another example, this time with the parent statement: PROGRAM foo USE m TYPE(t) :: a INTEGER :: i OPEN(10, FILE='file.txt', ACCESS='stream', FORM='formatted') WRITE(10, '(A)') '2*3 5 6' REWIND(10) READ(10, *) i, a !<-- parent READ encounters 2*3 PRINT *, i, a%i, a%j, ipos END PROGRAM The parent statement is the first statement to encounter 2*3. It transfers 3 to i, but cannot transfer the second constant to a list item. At the beginning of the user-defined procedure, the file should be positioned just before the number 5 (i.e. the rest of the 2*3 is ignored). Otherwise, the problem with file position reappears. Conclusion on F03/0051: Has not yet passed J3 letter ballot #13 - /interp will consider the above comment from Jim Xia at meeting #181 ---------------------------------------------------------------------- F03/0086 Elemental and BIND(C) Dick Hendrickson's YES comment on F03/0086: I agree with Bill Long's comment: ELEMENTAL is not an "attribute" in the sense that we use that term in the standard. Maybe something like "ELEMENTAL shall not be specified for a procedure with the BIND attribute.", or "An ELEMENTAL procedure shall not have the BIND attribute." Bill Long's YES comment on F03/0086: It would be helpful to include a reference for the edit: [280:6-7]. Also, ELEMENTAL is not an "attribute" in the sense that we use that term in the standard. Maybe something like "ELEMENTAL shall not be specified for a procedure with the BIND attribute.", or "An ELEMENTAL procedure shall not have the BIND attribute." Jim Xia's NO vote on F03/0086: I agree with the conclusion of the interp, but I see one minor issue in the edit. In F2003 standard, ELEMENTAL is never refered to as an attribute. Similarly but to a less degree, the term BIND attribute is mostly used for data objects but only a few places for procedures. A procedure with "BIND attribute" is regularly referred to be with . I'm willing to vote yes if the edit is changed to be consistent with the rest of the standard. A proposed edit: Replace C1242 in subclause 12.5.2.1 with "C1242 (R1227) A procedure shall not be specified with both ELEMENTAL and ." Conclusion on F03/0086: Passed J3 letter ballot #13 with the following change: Change the edit in 07-006A/F03/0086 to read: Replace C1242 in subclause 12.5.2.1 with [280:6-7] "C1242 An ELEMENTAL procedure shall not have the BIND attribute.". ---------------------------------------------------------------------- F03/0087 Entry names as dummy procedure arguments Dick Hendrickson's YES comment on F03/0087: I agree with Bill Long's comment: While we're fixing this constraint, we might as well fix the end of the sentence as well. The end is "nor shall appear in an EXTERNAL, INTRINSIC, or PROCEDURE statement". PROCEDURE statements, [258:27], appear only in interface blocks, and are not similar to EXTERNAL or INTRINSIC. I suspect we really meant procedure declaration statements [264:9]. Bill Long's YES comment on F03/0087: It would be helpful to include a reference for the edit: [283:10]. While we're fixing this constraint, we might as well fix the end of the sentence as well. The end is "nor shall appear in an EXTERNAL, INTRINSIC, or PROCEDURE statement". PROCEDURE statements, [258:27], appear only in interface blocks, and are not similar to EXTERNAL or INTRINSIC. I suspect we really meant procedure declaration statements [264:9]. Conclusion on F03/0087: Has not yet passed J3 letter ballot #13 - /interp will consider the above comment from Bill Long at meeting #181 ---------------------------------------------------------------------- F03/0088 Defined operations/assignments and VOLATILE/ASYNCHRONOUS Jim Xia's YES comment on F03/0088: Although the edit of this interp is correct, the declaration of the defined assignment used in the example is invalid. The declaration violates the rules specified for defined assignment at [263:8-10], which says the following Either the second argument shall be an array whose rank differs from that of the first argument, the declared types and kind type parameters of the arguments shall not conform as specified in Table 7.8, or the first argument shall be of derived type. Subroutine s declared in the interp can not be used to specify a user defined assignment for rank-one arrays of type real from another rank-one array of type real. A modified example is suggested as follows: INTERFACE ASSIGNMENT(=) SUBROUTINE s(a,b) REAL,INTENT(OUT),VOLATILE :: a(1,*) REAL,INTENT(IN) :: b(:) END SUBROUTINE END REAL,POINTER :: p(:,:),q(:) ... CALL s(p,q) ! Violation of constraint C1233 [271:9-11], ! associating P with A p = q ! No constraint violation because ! syntax is not being used Conclusion on F03/0088: Passed J3 letter ballot #13 with the above change in Jim Xia's ballot ---------------------------------------------------------------------- F03/0089 Interoperability of non-BIND derived types Conclusion on F03/0089: Passed J3 letter ballot #13 ---------------------------------------------------------------------- F03/0090 Polymorphic array constructors Jim Xia's NO vote on F03/0090: Answer (2) of the interp says an array constructor is non-polymorphic with declared type and dynamic type both of T. I see at least four problems with this answer: 1) There is no requirement anywhere in the standard for RHS expression be non-polymorphic in an intrinsic assignment. The array constructor can surely be interpreted as a polymorphic array, and the effect is the same as if a polymorphic pointer/ allocatable array appears as the RHS expression in the assignment. This interpretation will give the same results for the assignment. 2) There are other potential usage of an array constructor containing polymorphic entities, such as an actual argument to be associated with a polymorphic dummy array, a selector in ASSOCIATE or SELECT TYPE construct, a in an ALLOCATE statement for a polymorphic pointer/allocatable array. It's appropriate to interpret it as a polymorphic array with the same declared type and dynamic type as those appearing in the array constructor, respectively. 3) This interpretation prohibits use of unlimited polymorphic data in an array constructor because they don't have a declared type. There is no rationale in banning unlimited polymorphic entities in an array constructor. 4) The same effect of obtaining a non-polymorphic array constructor can already be achieved by using . Conclusion on F03/0090: Has not yet passed J3 letter ballot #13 - /interp will consider the above comment from Jim Xia at meeting #181 ---------------------------------------------------------------------- ---------------------------------------------------------------------- NUMBER: F03/0049 TITLE: Separators in list-directed output involving UDDTIO KEYWORDS: list-directed output, separators, UDDTIO DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the following program: MODULE m TYPE t INTEGER i END TYPE INTERFACE WRITE(FORMATTED) MODULE PROCEDURE formattedWriteT END INTERFACE CONTAINS SUBROUTINE formattedWriteT(dtv, unit, iotype, v_list, iostat, iomsg) CLASS(t), INTENT(IN) :: dtv INTEGER, INTENT(IN) :: unit CHARACTER(LEN=*), INTENT(IN) :: iotype INTEGER, INTENT(IN) :: v_list(:) INTEGER, INTENT(OUT) :: iostat CHARACTER(LEN=*), INTENT(INOUT) :: iomsg WRITE(unit, *) dtv%i, 'a' END SUBROUTINE END MODULE PROGRAM foo USE m TYPE(t) :: t1 = t(5) OPEN(10, FILE='foo.txt', ACCESS='SEQUENTIAL', FORM='FORMATTED', & DELIM='NONE') WRITE(10, *), 'xyz', t1, 'zyx' END PROGRAM 10.9.2 of Fortran 2003 states that character sequences produced for list-directed output are not separated from each other by value separators when the delimiter mode is NONE. The implication of this is obvious when the adjacent effective output list items are both of character type. But when user-defined derived-type input/output is involved, it is much less clear whether a separator should be included in the output. In the example given, it is unclear whether the output should be: xyz 5 azyx or: xyz 5 a zyx 1. Should a separator be inserted between two non-delimited character sequences when one of the character sequences is written by a child data transfer statement, and the other is written by a parent data transfer statement, where both statements are list-directed? 2. Should a separator be inserted between two non-delimited character sequences when the character sequences are written by two different child data transfer statements, where both statements are list-directed? 3. Should a separator be inserted between two character sequences when one of the character sequences is written by a child data transfer statement, and the other is written by a parent data transfer statement, where one of the statements is list-directed and the other is format-directed? 4. Should a separator be inserted between two character sequences when the character sequences are written by two different child data transfer statements, where one of the statements is list-directed and the other is format-directed? ANSWER: 1) No. It is the intent of the standard (10.9.2) that when both the parent and child data transfer statements are both list-directed output statements, or both are namelist output statements, the processor treats the first list item appearing in a child data transfer statement as if that list item had immediately followed the last list item processed by the parent data transfer statement, as long as no other data transfers to that unit occurred in between the processing of those two list items. Therefore, in this case, the two character sequences are considered adjacent. 2) No. It is the intent of the standard (10.9.2) that when two different child data transfer statements are both list-directed output statements, or both namelist output statements, they write to the same unit, and no other data transfers to that unit occur in between the two child data transfer statements, the processor treats the first list item appearing in the second child data transfer statement as if that list item had immediately followed the last list item processed by the first child data transfer statement. Therefore, in this case, the two character sequences are considered adjacent. 3) It is processor dependent whether or not a separator appears between two such character sequences. In section 10.9.2, the phrase "adjacent undelimited character sequences" refers to character sequences produced by list-directed output. When one of the sequences is written by a child or parent output statement that is not list-directed, the exception described in the first paragraph of 10.9.2 does not apply. The other rules for inserting optional blanks around values in list-directed output allow the processor to insert optional leading and trailing blanks around a list item. The standard does not specify when optional blanks are written; therefore, when two adjacent list items (the values thereof) are written to an output record, and only one of them was written by list-directed input/output, the standard does not specify whether or not any optional blanks appear between those values in the output record. 4) It is processor dependent whether or not a separator appears between two such character sequences. See answer 3. EDITS: [241:5+] In Section 10.9.2, add the following to the end of the first paragraph: "Two undelimited character sequences are considered adjacent when both were written using list-directed input/output, no intervening data transfer or input/output file positioning operations occurred, and both were written either by a single data transfer statement, or during the execution of a parent data transfer statement along with its child data transfer statements." SUBMITTED BY: Rob James HISTORY: 05-140 m171 F03/0049 Submitted 05-140r1 m171 Passed by J3 meeting 05-170 m172 Failed J3 letter ballot #11 06-367r1 m178 Passed by J3 meeting 07-xxx m181 Passed as changed by J3 letter ballot #13 ---------------------------------------------------------------------- NUMBER: F03/0050 TITLE: Questions about internal files KEYWORDS: internal file, data transfer DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot QUESTIONS: Question 1: Fortran 2003 does not seem to prohibit this kind of recursive internal input/output. Was this program intended to be standard-conforming? If so, then what does the program print? MODULE m1 CHARACTER(20) :: ifile = '' CONTAINS CHARACTER(3) FUNCTION foo() WRITE(ifile, *) 'QWERTY' foo = 'abc' END FUNCTION END MODULE PROGRAM ex1 USE m1 WRITE(ifile, *) 'xyz', foo(), 'zyx' PRINT *, ifile END PROGRAM Question 2: Fortran 2003 does not seem to prohibit this kind of recursive internal Iinput/output. Was this program intended to be standard-conforming? If so, then what does the program print? MODULE m2 CHARACTER(20) :: ifile = 'abc def ghi jkl mno ' CHARACTER(3) :: char CONTAINS CHARACTER(3) FUNCTION foo() READ(ifile, *) char foo = 'abc' END FUNCTION END MODULE PROGRAM ex2 USE m2 WRITE(ifile, *) 'xyz', foo(), 'zyx' PRINT *, ifile PRINT *, char END PROGRAM Question 3: Fortran 2003 does not appear to prohibit modifying a character variable when it is being used as an internal file in a data transfer statement that is currently executing. Was this program intended to be standard-conforming? If so, then what does the program print? MODULE m3 CHARACTER(20) :: ifile = '' CONTAINS CHARACTER(3) FUNCTION foo() ifile = 'bad thing to do?' foo = 'abc' END FUNCTION END MODULE PROGRAM ex3 USE m3 WRITE(ifile, *) 'xyz', foo(), 'zyx' PRINT *, ifile PRINT *, flag END PROGRAM Question 4: Fortran 2003 does not appear to prohibit referencing a character variable when it is being used as an internal file in a data transfer statement that is currently executing. Was this program intended to be standard-conforming? If so, then what does the program print? MODULE m4 CHARACTER(20) :: ifile = '' LOGICAL :: flag = .FALSE. CONTAINS CHARACTER(3) FUNCTION foo() IF (ifile == ' xyz') THEN flag = .TRUE. END IF foo = 'abc' END FUNCTION END MODULE PROGRAM ex4 USE m4 WRITE(ifile, *) 'xyz', foo(), 'zyx' PRINT *, ifile PRINT *, flag END PROGRAM ANSWER: All of these examples were intended to be prohibited. Edits are provided to prohibit referencing or defining a variable used as an internal unit as a result of evaluating any output list items, or transferring values to any input list item. EDITS: In section 9.5.3.4, after the paragraph: "If an internal file has been specified, an input/output list item shall not be in the file or associated with the file." add these paragraphs [196:29+]: "During the execution of an output statement that specifies an internal file, no part of that internal file shall be referenced, defined, or become undefined as the result of evaluating any output list item. During the execution of an input statement that specifies an internal file, no part of that internal file shall be defined or become undefined as the result of transferring a value to any input list item." SUBMITTED BY: Rob James HISTORY: 05-141 m171 F03/0050 Submitted 06-368 m178 Passed by J3 meeting 07-xxx m181 Passed as changed by J3 letter ballot #13 ---------------------------------------------------------------------- NUMBER: F03/0086 TITLE: Elemental and BIND(C) KEYWORDS: Elemental, BIND(C), ENTRY DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Is it allowed for a procedure to have both the BIND(C) and elemental attributes? Constraint C1242 disallows trivial ways of writing an elemental BIND(C) procedure. However, the following example achieves the effect for sub_c without violating the syntactic constraint. elemental subroutine sub(x) entry sub_c(x) bind(c) end subroutine sub ANSWER: No, it is not allowed. Constraint C1242 was intended to disallow the combination of elemental and BIND(C), but it inadvertently failed to cover the case shown in the above example. EDITS Replace C1242 in subclause 12.5.2.1 with [280:6-7] "C1242 An ELEMENTAL procedure shall not have the BIND attribute.". SUBMITTED BY: Richard Maine HISTORY: 07-101 m179 Submitted F03/0086 07-101 m179 Passed by J3 meeting 07-xxx m181 Passed as changed by J3 letter ballot #13 ---------------------------------------------------------------------- NUMBER: F03/0088 TITLE: Defined operations/assignments and VOLATILE/ASYNCHRONOUS KEYWORDS: Defined operations, defined assignment, VOLATILE, ASYNCHRONOUS DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot PROBLEM: Fortran 2008 Unresolved Technical issue 097 asked a question that also affects Fortran 2003. Consider this example: INTERFACE ASSIGNMENT(=) SUBROUTINE s(a,b) REAL,INTENT(OUT),VOLATILE :: a(1,*) REAL,INTENT(IN) :: b(:) END SUBROUTINE END REAL,POINTER :: p(:,:),q(:) ... CALL s(p,q) ! Violation of constraint C1233 [271:9-11], ! associating P with A p = q ! No constraint violation because ! syntax is not being used QUESTION: Did Fortran 2003 intend to enforce constraints on in defined assignment? ANSWER: Yes, the constraints and restrictions should be enforced in defined assignment and in defined operator evaluation. Edits are provided below to do this. EDITS: [262:16] add at the end of the paragraph " All restrictions and constraints that apply to actual arguments in a reference to the function also apply to the corresponding operands in the expression as if they were used as actual arguments." [263:12] insert after "the second argument." " All restrictions and constraints that apply to actual arguments in a reference to the subroutine also apply to the left-hand-side and to the right-hand-side enclosed in parentheses as if they were used as actual arguments." SUBMITTED BY: Stan Whitlock HISTORY: 07-172 m179 Submitted F03/0088 {see 07-171 for F08 fix} 07-172 m179 Passed by J3 meeting 07-xxx m181 Passed as changed by J3 letter ballot #13 ---------------------------------------------------------------------- NUMBER: F03/0089 TITLE: Interoperability of non-BIND derived types KEYWORDS: Interoperability, derived type DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot INTRODUCTION Subclause 15.2.3 of 04-007 says [398:9-12]: "A Fortran derived type is interoperable with a C struct type if the derived-type definition of the Fortran type specifies BIND(C) (4.5.1), the Fortran derived type and the C struct type have the same number of components, and the components of the Fortran derived type have types and type parameters that are interoperable with the types of the corresponding components of the struct type." QUESTIONS 1. Is a Fortran derived type for which BIND(C) is not specified interoperable with any C struct type? 2. Does a Fortran derived type interoperate with a C struct type that has a different number of components? 3. Does a Fortran derived type interoperate with a C struct type that specifies the same components in a different order? 4. Does a Fortran derived type with a pointer or allocatable component that has interoperable type and type parameters interoperate with any C struct type? ANSWERS: None of these Fortran derived types are interoperable with any C struct type. EDITS: [398:9] Replace "if" by "if and only if". SUBMITTED BY: Van Snyder HISTORY: 07-213 m180 Submitted F03/0089 07-213r2 m180 Passed by J3 meeting 07-xxx m181 Passed by J3 letter ballot #13 ----------------------------------------------------------------------