To: J3 11-255r1
From: Stan Whitlock
Date: 2011 October 13
Subject: interp F03/0120
References: 10-007r1, 11-241, 11-229, 04-007
Interp F03/0120 failed {11-241} interp letter ballot #24 {11-229}:
The editorial fixes suggested will be made to the interp. The issue
of whether this is an incompatibility with F2003 needs to be resolved,
=> F03/0120 fails.
The edits herein do introduce an incompatibility with F2003: SEQUENCE
derived types were allowed to have type parameters in F2003 since they
were not prohibited {04-007 4.5.1.2 [46:13-15]}. An edit is added here
to call out this incompatibility in F2008.
Note that F08/0011 already added an incompatibility in F2008 with F2003
and passed WG5 ballot #1 (N1876/N1878) so the introductory text in
10-007r1 1.6.2 [24:9] has already been edited:
[24:9] Change the first word of 1.6.2p1
"This" -> "Except as identified in this subclause, this".
This interp adds a paragraph in section 1.6.2 to call out the
incompatibility created by this interp answer.
---------------------------------------------------------------------
NUMBER: F03/0120
TITLE: When are parameterized sequence types the same type?
KEYWORDS: type parameter, sequence type
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
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.
This change introduces an incompatibility in F2008 with F2003.
An edit to F2008 section 1.6.2 points this out.
EDITS to 10-007r1:
[24:11+] Insert new paragraph after 1.6.2p1:
"Fortran 2003 allowed sequence types to have type parameters.
This part of ISO/IEC 1539 specifies that sequence types may
not have type parameters."
Replace constraint C436 on line 19 of page 62 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 type-bound-procedure-part shall not
appear.
Delete the phrase "type parameters and" from line 9 of
page 63.
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
11-255 m196 Revised answer
11-255r1 m196 Passed by J3 meeting
---------------------------------------------------------------------