12-132 To: J3 From: Malcolm Cohen Subject: Parameterised sequence types Date: 2012 February 15 ---------------------------------------------------------------------- NUMBER: F03/0120 TITLE: When are parameterized sequence types the same type? KEYWORDS: type parameter, sequence type DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: (1) What does 4.5.2.4 mean by the phrase "have type parameters and components that agree in order, name, and attributes?" Does REAL A(2*N) "agree" with REAL A(N+N) ? Does REAL A(N*N) "agree" with REAL A(N**2) ? (2) How complicated can the expressions a processor must determine are equal or different be? DISCUSSION: The Fortran 2008 standard allows sequence types to have type parameters (4.5.2, 4.5.2.3). The Fortran 2008 standard also gives rules for deciding when two entities declared with reference to derived-type definitions have the same type (4.5.2.4). Those rules break down for parameterized sequence types. Although the Fortran 2008 standard does not explicitly say it, the standard assumes that two attributes that include one or more expressions agree only if the values of those expressions are the same. Previous standards used attributes with expressions that could not be evaluated statically only in contexts where the processor was not required to determine if those attributes agreed. The inclusion of parameterized sequence types has created situations where it is necessary for the processor to determine if such attributes agree. QUESTION: (3) Consider the modules MODULE M1 TYPE T(N) INTEGER(KIND=4), KIND :: N SEQUENCE REAL A(2*N) END TYPE TYPE(T(4)) :: X END MODULE M2 TYPE T(N) INTEGER(KIND=4), KIND :: N SEQUENCE REAL A(N+N) END TYPE TYPE(T(4)) :: Y END Are the variables X and Y in this example of the same type? (4) What if the two instances of the type parameter N in the previous example were not kind type parameters? (5) Consider the modules MODULE M1 INTERFACE S SUBROUTINE S1(X, M) TYPE T(N) INTEGER, LEN :: N SEQUENCE REAL A(N+N) END TYPE TYPE(T(M)) :: X END SUBROUTINE END INTERFACE TYPE T(N) INTEGER, LEN :: N SEQUENCE REAL A(N+N) END TYPE TYPE(T(2)) :: X END MODULE M2 INTERFACE S SUBROUTINE S2(X, M) TYPE T(N) INTEGER, LEN :: N SEQUENCE REAL A(2*N) END TYPE TYPE(T(M)) :: X END SUBROUTINE END INTERFACE TYPE T(N) INTEGER, LEN :: N SEQUENCE REAL A(2*N) END TYPE TYPE(T(2)) :: X END If these two modules are used in the same scoping unit and there is a CALL of the generic subroutine S in that scoping unit, does the Fortran 2008 standard require a conforming processor to detect and report the conflict with the rules given in 12.4.3.4.5? It seems it might or might not depending on one's interpretation of item (6) in 1.5. DISCUSSION: Some have suggested that two attributes that include expressions should be said to agree if and only if the corresponding expressions are equivalent. One problem with that notion is that in general the question of whether two expressions are equivalent is undecidable. That problem could be circumvented by restricting the forms of expressions allowed. For example, the expressions might be restricted to be polynomials of one or more variables. In that case, the problem of determining equivalence is merely intractable, not impossible. Some have suggested that the notion of requiring only that the values agree should be maintained. One consequence of that would be that some constraint violations that are can currently be detected statically could only be detected dynamically. For example, consider the program MODULE M1 TYPE T(N) INTEGER(KIND=4), LEN :: N SEQUENCE REAL A(N+N) END TYPE END MODULE M2 TYPE T(N) INTEGER(KIND=4), LEN :: N SEQUENCE REAL A(N*N) END TYPE END SUBROUTINE S(N) USE M1, T1=>T USE M2, T2=>T TYPE(T1(N)) :: X TYPE(T2(N)) :: Y Y%A = 0.0 X = Y END PROGRAM MAIN READ *, N CALL S(N) END Under the interpretation requiring equal values, the question of whether the processor must detect and report a constraint violation in the assignment X = Y cannot be determined until the value of N is known. Another suggestion was that attributes that include expressions agree if and only if they are textually equivalent. That opens up the question of what it means to say that two expressions are textually equivalent. Does whitespace count? Is "2" textually equivalent to "02"? It "2" textually equivalent to a named constant "TWO" whose value is two? Another suggestion was that two entities declared with reference to derived-type definitions in different scoping units should be considered to be of different if either or both of the derived-type definitions include type parameters. At least that solution is easy to specify. Parameterized sequence types add so little value to the Fortran language that they cannot be worth the trouble they cause for the language specification, for implementors, and, if there are any users, for users. Therefore, I suggest banning parameterized sequence types from the language. Implementations that currently support parameterized sequence types can continue to support them due to the permissive nature of the Fortran standard. ANSWER: It was not intended that parameterized derived types participate in the algorithm for determining when two types are the same, as given in section 4.5.2.4. Therefore the answers to the questions are: Not Applicable, Not Applicable, No, Still No, and No. To make this effective, edits are supplied which ban parameterized sequence types from the language. EDITS to 10-007r1: [24:11+] Append new paragraph to 1.6.2 Fortran 2003 compatibility "Fortran 2003 permitted a sequence type to have type parameters; that is not permitted by this part of ISO/IEC 1539." [62:19] 4.5.2.3 Sequence type, Replace constraint C436 with "C436 (R425) If SEQUENCE appears, each data component shall be declared to be of an intrinsic type or of a sequence type, the derived type shall not have type parameters, and a shall not appear." [63:9] 4.5.2.4 Determination of derived types, paragraph 2, delete the phrase "type parameters and". SUBMITTED BY: Robert Corbett HISTORY: 08-261 m185 F03/0120 submitted 11-224 m195 Revised answer - Passed by J3 meeting 11-241 m196 Failed J3 letter ballot #24 11-229 12-132 m197 Revised edits. ----------------------------------------------------------------------