J3/11-101 To: J3 From: Van Snyder Subject: Ordering requirements on definition of specification functions Date: 2011 November 03 ---------------------------------------------------------------------- NUMBER: F08/xxxx TITLE: Ordering requirements on definition of specification functions KEYWORDS: Specification expressions, specification functions DEFECT TYPE: Erratum 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 blunder. 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 a 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 a host scoping unit, subsequent to the constant expression." SUBMITTED BY: Van Snyder HISTORY: 11-xxx m194 Revision of F95/0030 submitted F08/xxxx ----------------------------------------------------------------------