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.
----------------------------------------------------------------------