11-156 To: J3 Members From: Stan Whitlock Subject: J3 Fortran interp letter ballot #23 - due 25-Mar-2011 Date: 2011 February 18 Enclosed in the next letter ballot on Fortran interpretations. The rules by which we operate say: o J3 votes on the answer at a J3 meeting; a simple majority vote marks the answer as "passed by J3 meeting". o Between J3 meetings the chair of /interp sends a J3 letter ballot to J3 to approve interp answers that have been "passed by J3 meeting". The letter ballot runs for 30 days. Not voting on three of four consecutive J3 letter ballots is grounds to terminate J3 membership. An interp answer passes by a 2/3rds vote; a no vote must be accompanied by an explanation of the changes necessary to change the member's vote to yes. J3/interp reserves the right to recall an interp answer for more study even if the answer passes. 6 Fortran interpretations are currently "Passed by J3 meeting" after J3 meeting #194. This is the letter ballot phase to go from "Passed by J3 meeting" to "Passed by J3 letter ballot". The following Fortran interpretations are being balloted: Yes No Number Title --- --- F03/0124 Definition is poorly defined --- --- F08/0050 Ordering requirements on definition of specification functions --- --- F08/0051 Pure procedure arguments with VALUE --- --- F08/0052 Private type-bound procedures --- --- F08/0053 Restrictions on generic declarations, generic resolution --- --- F08/0054 Requirements for needing an explicit interface The text of these interpretations is attached. Each interpretation starts with a row of "-"s. Please mark the above -Y- in the Yes column for "yes", -C- in the Yes column for "yes with comment", or -N- in the No column for a "no" answer {be sure to include your reasons with "no"} and send only the above text {not this entire mail message} with any comments to j3@j3-fortran.org by 11:59:59PM, PDT, Friday, 25-Mar-2011, in order to be counted. Thanks /Stan ---------------------------------------------------------------------- NUMBER: F03/0124 TITLE: Definition is poorly defined KEYWORDS: definition DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider the program: PROGRAM example1 TYPE T1 SEQUENCE INTEGER I, J END TYPE TYPE T2 SEQUENCE INTEGER I, J END TYPE TYPE(T1) X TYPE(T2) Y EQUIVALENCE (X, Y) X%I = 1 X%J = 2 PRINT *, X, Y END Q1. Is this program standard-conforming, and if so, what does it print? According to items (1) and (12) of 16.6.5, the assignment to X%I causes both X%I and Y%I to become defined. Similarly, the assignment to X%J causes both X%J and Y%J to become defined. Then, according to item (15) of 16.6.5, both X and Y become defined. However, according to 4.5.2.4, X and Y are types with different names, and therefore are of different type, thus according to 16.6.6 item (1) when X becomes defined Y becomes undefined, and vice versa. This appears to be a contradiction. Furthermore, consider PROGRAM example2 TYPE t INTEGER a,b END TYPE TYPE(t),TARGET :: x INTEGER,POINTER :: p x = t(1,2) p => x%a p = 33 PRINT *,x END PROGRAM According to the quoted text, the assignment to P is defining a variable of type INTEGER, and one that is associated (partially, via pointer association) with a variable of type T. That would seem to make X undefined according to item (1) of 16.6.6. Q2. Is example2 intended to be standard-conforming? Finally, consider MODULE ugly1 TYPE t1 INTEGER a,b END TYPE INTEGER w,z TYPE(t1) x COMMON/c/w,x,z END MODULE MODULE ugly2 TYPE t2 INTEGER c,d END TYPE TYPE(t2) y1,y2 COMMON/c/y1,y2 END MODULE BLOCK DATA COMON/c/i(4) DATA i/1,2,3,4/ END BLOCK DATA PROGRAM example3 USE ugly1 USE ugly2 ! At this point c is 1,2,3,4. y1 = t2(66,-6) PRINT *,w ! Is this ok? w = 0 PRINT *,y1 ! And is this ok? END PROGRAM This is similar to example1, except that we are defining a whole variable of sequence type at once, not by partial definition. Q3. Is example3 standard-conforming? ANSWER: A1. The program was intended to be standard-conforming. An edit is supplied to remove the apparent contradiction. The program should print something like " 1 2 1 2". A2. Yes, example2 is intended to be standard-conforming. An edit is supplied to remove the problem. A3. Yes, example3 is intended to be standard-conforming. An edit is supplied to remove the problem. DISCUSSION: The only interesting case of variable definition causing an associated variable to become undefined is using the old FORTRAN 77 data types; all the other intrinsic types are not permitted to be associated with variables of different type. We only need to get the scalar intrinsic case right, as the array and derived type cases then follow automatically from the definitions in 16.6.1. EDITS: [455:4-10] Replace 16.6.6 item (1) entirely: "(1) When a scalar variable of intrinsic type becomes defined, all totally associated variables of different type become undefined. (1a) When a double precision scalar variable becomes defined, all partially associated scalar variables become undefined. (1b) When a scalar variable becomes defined, all partially associated double precision scalar variables become undefined." [455:36] Change "(1)" to "(1)-(1b)". {Fix reference.} SUBMITTED BY: Robert Corbett (via Van Snyder via Dan Nagle) HISTORY: 08-269 m185 F03/0124 submitted 10-245 m193 Draft answer - Passed by J3 meeting 11-129 m194 Failed J3 letter ballot #22 10-254 11-150 m194 Revised answer - Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0050 TITLE: Ordering requirements on definition of specification functions KEYWORDS: Specification expressions, specification functions DEFECT TYPE: Erratum STATUS: Passed by J3 meeting REFERENCE: F95/0030 BACKGROUND (can be skipped without significant loss): F95/0030 asked to consider the following program unit. MODULE MOD INTERFACE INT MODULE PROCEDURE F1, F2 END INTERFACE CONTAINS INTEGER PURE FUNCTION F1(I) INTEGER :: A(INT(1_4)), B(INT(1_2)) ! A(1), B(19) INTEGER, PARAMETER :: KIND = SIZE(A) ! KIND == 1 INTEGER(KIND), INTENT(IN) :: I F1 = 17 END FUNCTION F1 INTEGER PURE FUNCTION F2(J) INTEGER :: C(INT(2_4)) ! C(2) INTEGER, PARAMETER :: KIND = SIZE(C) ! KIND == 2 INTEGER(KIND), INTENT(IN) :: J F2 = 19 END FUNCTION F2 END MODULE MOD In processing the references to "INT(1_4)" and "INT(1_2)" in F1, the processor needs to determine whether the references are to the intrinsic function, INT, or to one of the specific procedures, F1 or F2. Determining that requires the processor to have determined the kind type parameter of the dummy argument J, of F2. In turn, that requires the processor to determine whether the reference to "INT(2_4)" is a reference to the intrinsic function, INT, or to one of the specific procedures, F1 or F2. Determining that requires the processor to determine the kind type parameter of the dummy argument I, which requires it to determine that "INT(1_4)" in F1 was a reference to the intrinsic function INT. After all this is determined, the processor can determine that the reference to "INT(1_2)" in the declaration of B in F1 is a reference to the specification function F2. According to F95/7.1.6.1 [97-007r2:94:38-41], "If an initialization expression includes a reference to an inquiry function for a type parameter or an array bound of an object specified in the same , the type parameter or array bound shall be specified in a prior specification of the . The prior specification may be to the left of the inquiry function in the same statement." or F03/7.1.7 [04-007:30-33] "If an initialization expression includes a specification inquiry that depends on a type parameter or an array bound of an entity specified in the same , the type parameter or array bound shall be specified in a prior specification of the . The prior specification may be to the left of the specification inquiry in the same statement, but shall not be within the same ." or F08/7.1.12 [10-007:152:22-25] "If a constant expression includes a specification inquiry that depends on a type parameter or an array bound of an entity specified in the same , the type parameter or array bound shall be specified in a prior specification of the . The prior specification may be to the left of the specification inquiry in the same statement, but shall not be within the same ." According to F95/7.1.6.2 [97-007r2:96:27-37], "A variable in a specification expression shall have its type and type parameters, if any, specified by a previous declaration in the same scoping unit, or by the implicit typing rules in effect for the scoping unit, or by host or use association. If a variable in a specification expression is typed by the implicit typing rules, its appearance in any subsequent type declaration statement shall confirm the implied type and type parameters. "If a specification expression includes a reference to an inquiry function for a type parameter or an array bound of an entity specified in the same , the type parameter or array bound shall be specified in a prior specification of the . The prior specification may be to the left of the inquiry function reference in the same statement. If a specification expression includes a reference to the value of an element of an array specified in the same , the array shall be completely specified in prior declarations." or F03/7.1.6 [126:9-14] "A variable in a specification expression shall have its type and type parameters, if any, specified by a previous declaration in the same scoping unit, by the implicit typing rules in effect for the scoping unit, or by host or use association. If a variable in a specification expression is typed by the implicit typing rules, its appearance in any subsequent type declaration statement shall confirm the implied type and type parameters. "If a specification expression includes a specification inquiry that depends on a type parameter or an array bound of an entity specified in the same , the type parameter or array bound shall be specified in a prior specification of the . The prior specification may be to the left of the specification inquiry in the same statement, but shall not be within the same . If a specification expression includes a reference to the value of an element of an array specified in the same , the array shall be completely specified in prior declarations." or F08/7.1.11 [10-007:3-12] "A variable in a specification expression shall have its type and type parameters, if any, specified by a previous declaration in the same scoping unit, by the implicit typing rules in effect for the scoping unit, or by host or use association. If a variable in a specification expression is typed by the implicit typing rules, its appearance in any subsequent type declaration statement shall confirm the implied type and type parameters. "If a specification expression includes a specification inquiry that depends on a type parameter or an array bound of an entity specified in the same , the type parameter or array bound shall be specified in a prior specification of the . The prior specification may be to the left of the specification inquiry in the same statement, but shall not be within the same . If a specification expression includes a reference to the value of an element of an array specified in the same , the array shall be completely specified in prior declarations." The rules regarding references to variables in specification expressions and initialization expressions require a strict left-to-right, top-to-bottom ordering between specification and inquiry. Specification functions appear to be unrestricted in this respect. Interp F95/0030 added the following new paragraph immediately before F03/Note 7.11 [04-007:127:33+] If an initialization expression in a module includes a reference to a generic, that generic shall have no specific procedures defined in the module subsequent to the initialization expression. And the following new paragraph immediately before F03/Note 7.10 [04-007:126:19+]: If a specification expression in a module includes a reference to a generic, that generic shall have no specific procedures defined in the module subsequent to the specification expression. QUESTION: The new paragraphs introduced into F03 by F95/0030, at [04-007:127:33+] and [04-007:126:19+], were changed in F08. The additional caveat "or submodule" was harmlessly introduced in four places by TR 19767. Paper 07-190r3 introduced "the of" in F08/7.1.12p3 [10-007:152:26-28] If a constant expression in the of a module or submodule includes a reference to a generic entity, that generic entity shall have no specific procedures defined in the module or submodule subsequent to the constant expression. and F08/7.1.11p9 [10-007:151:13-15] If a specification expression in the of a module or submodule includes a reference to a generic entity, that generic entity shall have no specific procedures defined in the module or submodule subsequent to the specification expression. Because of the changes introduced in F08 by 07-190r3, the paragraphs no longer address the question of interpretation request F95/0030, resulting in the example in the F95/0030 being standard conforming, contrary to the ANSWER to F95/0030. In light of F08 allowing generic interfaces to have specific procedures that are internal procedures, the following example illustrates a deeper problem than was illustrated in F95/0030: SUBROUTINE SUB INTERFACE INT PROCEDURE F1, F2 END INTERFACE CONTAINS INTEGER PURE FUNCTION F1(I) INTEGER :: A(INT(1_4)), B(INT(1_2)) ! A(1), B(19) INTEGER, PARAMETER :: KIND = SIZE(A) ! KIND == 1 INTEGER(KIND), INTENT(IN) :: I F1 = 17 END FUNCTION F1 INTEGER PURE FUNCTION F2(J) INTEGER :: C(INT(2_4)) ! C(2) INTEGER, PARAMETER :: KIND = SIZE(C) ! KIND == 2 INTEGER(KIND), INTENT(IN) :: J F2 = 19 END FUNCTION F2 END SUBROUTINE SUB Assuming that the processor supports integers with kind type parameters of 1, 2 and 4, was it the intent of the committee that this program unit example should be standard-conforming? ANSWER: No, it is clear from the answer to interpretation request F95/0030 that it is not the intent that the above program unit be standard conforming. The required complexity of implementation is not justified. The standard (as amended by corrigenda) briefly had prohibitions against it, but they were inadvertently removed during development of Fortran 2008. The edits below correct this. EDITS: Replace F08/7.1.11p9 [10-007:151:13-15] by "A generic entity referenced in a specification expression in the of a scoping unit shall have no specific procedures defined in that scoping unit, or its host scoping unit, subsequent to the specification expression." Replace F08/7.1.12p3 [10-007:152:26-28] by "A generic entity referenced in a constant expression in the of a scoping unit shall have no specific procedures defined in that scoping unit, or its host scoping unit, subsequent to the constant expression." SUBMITTED BY: Van Snyder HISTORY: 11-101 m194 F08/0050 submitted - revision of F95/0030 11-101r1 m194 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0051 TITLE: Pure procedure arguments with VALUE KEYWORDS: INTENT, PURE, VALUE DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider PURE FUNCTION F(X) REAL,VALUE :: X F = X**2 END FUNCTION This subprogram does not conform to the Fortran 2003 standard, but appears to conform to the Fortran 2008 standard, as constraints C1276 and C1277 (in Fortran 2008) have been modified to remove the previous requirement for an INTENT specification in the case of arguments that have the VALUE attribute. However, this is not mentioned as a change in the Introduction. Was this change inadvertent? ANSWER: No, this change was deliberate. An edit is provided to clarify. EDITS: [xvi] Introduction, paragraph 2, last bullet point: Before "An impure" Insert the new sentence "An argument to a pure procedure may have default INTENT if it has the VALUE attribute.". SUBMITTED BY: Malcolm Cohen HISTORY: 11-139 m194 F08/0051 submitted - passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0052 TITLE: Private type-bound procedures. KEYWORDS: Type extension, type-bound procedures, accessibility. DEFECT TYPE: Erratum. STATUS: Passed by J3 meeting QUESTION: Consider the program MODULE example1_m1 TYPE t1 CONTAINS PROCEDURE,PRIVATE,NOPASS :: p ! (1). END TYPE CONTAINS SUBROUTINE p PRINT *,'p' END SUBROUTINE SUBROUTINE do_p(x) CLASS(t1) x CALL x%p END SUBROUTINE END MODULE MODULE example1_m2 USE example1_m1 TYPE,EXTENDS(t1) :: t2 CONTAINS PROCEDURE,NOPASS :: p => p2 ! (2). END TYPE CONTAINS SUBROUTINE p2(n) PRINT *,'p2',n END SUBROUTINE END MODULE PROGRAM example1 USE example1_m2 TYPE(t2),TARGET :: x CLASS(t1),POINTER :: y y => x CALL do_p(x) ! (3): I expect this to print 'p'. CALL do_p(y) ! (4): I expect this to print 'p'. CALL x%p(13) ! (5): I expect this to print 'p2 13'. END PROGRAM Question 1: does type-bound procedure overriding take account of accessibility; that is, is the type-bound procedure statement at (2) (a) a valid new type-bound procedure definition, or (b) an invalid overriding of the definition at (1)? Question 2: If the answer to question 1 was "yes" (a), and the example is standard-conforming, are the expectations at (3), (4), and (5) correct? For the next question, consider the following program fragment: MODULE example2_m1 TYPE,ABSTRACT :: t1 CONTAINS PROCEDURE(p),PRIVATE,DEFERRED,NOPASS :: hidden ! (6). END TYPE CONTAINS SUBROUTINE p PRINT *,'p' END SUBROUTINE END MODULE MODULE example2_m2 USE example2_m1 TYPE,EXTENDS(t1) :: t2 CONTAINS PROCEDURE,NOPASS :: hidden => exposed ! (7). END TYPE CONTAINS SUBROUTINE exposed PRINT *,'exposed' END SUBROUTINE END MODULE Question 3: If the answer to question 1 was "yes" (a), then the definition of type t2 would seem to be defective in that (7) must be defining a new type-bound procedure, and not overriding the type-bound procedure defined at (6), and that therefore t2 still has a deferred type-bound procedure. That would mean that an abstract type with a private deferred type-bound procedure could not be extended outside of the module in which it is defined: is that correct? ANSWER: Q1. Yes, type-bound procedure overriding does take account of accessibility. This means that the type-bound procedure statement at (2) is (a) a valid new type-bound procedure definition. Subclause 4.5.7.3 says [78:4-6] "If a specific type-bound procedure specified in a type definition has the same binding name as a type-bound procedure from the parent type then [it] overrides the [inherited one]." If the inherited type-bound procedure is private, and the extending type definition is not in the same module, then the inherited type-bound procedure is not accessible by that name, so the condition "has the same binding name" cannot be satisfied. An edit is suggested for a future revision to make this wording clearer. Q2. Yes, the comments at (3), (4), and (5) are accurate. Q3. Yes, an abstract type with a private deferred type-bound procedure cannot be extended outside the defining module, because it is otherwise impossible to override the private type-bound procedure. EDITS to 10-007r1: [78:4] In 4.5.7.3p1, change "as a type-bound" to "as an accessible type-bound". SUBMITTED BY: Malcolm Cohen HISTORY: 11-141 m194 F08/0052 submitted - passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0053 TITLE: Restrictions on generic declarations, generic resolution KEYWORDS: generic declarations, generic resolution DEFECT TYPE: Erratum STATUS: Passed by J3 Meeting BACKGROUND: There is a specification in 12.4.3.4 [283] of the properties that cause two dummy arguments to be distinguishable. C1214 [286] specifies that two procedures within the scope of a shall be distinguishable. There is no specification of the properties that cause two procedures to be distinguishable. 12.4.3.4.5p5 [286:38] specifies that a "generic invocation applies to...." QUESTIONS: (1) Shouldn't the requirement in C1214 be that the \cf{dtv} arguments are distinguishable? (2) Shouldn't 12.4.3.4.5p5 specify that a "generic invocation is consistent with...?" ANSWERS: (1) Yes. (2) Yes. Edits are provided to clarify these two issues. EDITS to 10-007r1: [286:12-13 C1214] Editor: Replace "two ... identifier" by "if two procedures have the same generic identifier, their \cf{dtv} arguments". Insert "(9.6.4.8.3)" somewhere (your choice). [286:38 12.4.3.4.5p5] Editor: Replace "applies to" by "is consistent with". SUBMITTED BY: Van Snyder HISTORY: 11-136r2 m194 Submitted F08/0053 in section 2 11-136r1 m194 Passed section 1 - Editorial edits 11-136r3 m194 Section 2 passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F08/0054 TITLE: Requirements for needing an explicit interface KEYWORDS: Explicit interface DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider the program SUBROUTINE Fred() BIND(C,NAME='Nurke') PRINT *,'ok' END SUBROUTINE SUBROUTINE S(dummy) INTERFACE SUBROUTINE dummy() BIND(C) END SUBROUTINE END INTERFACE CALL dummy END SUBROUTINE PROGRAM example1 EXTERNAL Fred,S CALL S(Fred) END PROGRAM According to 12.4.2.2, an explicit interface is only ever required in a scope where a procedure is referenced. The main program does not reference Fred, so this appears to be conforming. It appears that no processors accept this example... However, the very similar program minus the BIND(C) specifications SUBROUTINE Freddy(x) LOGICAL,OPTIONAL :: x IF (PRESENT(x)) PRINT *,'ok' END SUBROUTINE SUBROUTINE SUB(dummy) INTERFACE SUBROUTINE dummy(x) LOGICAL,OPTIONAL :: x END SUBROUTINE END INTERFACE CALL dummy(.TRUE.) END SUBROUTINE PROGRAM example2 EXTERNAL Freddy,SUB CALL SUB(Freddy) END PROGRAM but with a different reason for requiring an explicit interface, is also apparently valid in Fortran 2003/2008 but is not valid in Fortran 90 or Fortran 95, because they require the explicit interface without the condition of the procedure being referenced in that scope. This feature (viz only require the explicit interface where it is referenced) was added by paper 02-144, which makes no mention of it being a new feature. Was this a deliberate new feature? ANSWER: No, this was a mistake in 02-144 and thus in Fortran 2003 and 2008. An edit is provided to correct the mistake. EDITS to 10-007r1: In 12.4.2.2p1, delete "it is referenced and" [279:19]. SUBMITTED BY: Malcolm Cohen HISTORY: 11-135 m194 F08/0054 submitted 11-135r1 m194 Passed by J3 meeting ----------------------------------------------------------------------