(j3.2006) derived types with type parameters are different
Robert Corbett
Robert.Corbett
Tue Jul 29 01:31:52 EDT 2008
Here is the RFI I wrote about this matter yesterday (with edits
for errors similar to those pointed out earlier by Bill Long).
I was lucky that my first example is one where existing
implementations differ. I hope this RFI makes my intention
clear. I hope Sun's representative to the committee filed it
in time for the two week deadline.
Robert Corbett
----------------------------------------------------------------
NUMBER: F03/ ! /interp assigns number after submission
TITLE: When are parameterized sequence types the same type?
KEYWORDS: type parameter sequence type
DEFECT TYPE: ! /interp assigns
STATUS: J3 consideration in progress
QUESTION:
What does 4.5.1.3 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) ?
How complicated can the expressions a processor must
determine are equal or different be?
The Fortran 2003 standard allows sequence types to have type
parameters (4.5.1, 4.5.1.2). The Fortran 2003 standard also
gives rules for deciding when two entities declared with
reference to derived-type definitions have the same
type (4.5.1.3). Those rules break down for parameterized
sequence types.
Although the Fortran 2003 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.
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? What if the two instances of the type parameter N
were not kind type parameters?
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, the Fortran 2003 standard might or might
not require a conforming processor to detect and report
the conflict with the rules given in 16.2.3, depending
on one's interpretation of item (6) in 1.5.
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(T(N)) :: X
TYPE(T(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.
ANSWER:
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.
EDITS:
Replace constraint C433 on line 15 of page 46 with
with
C433 (R429) If SEQUENCE appears, the derived-type
shall not have type parameters and the
type-bound-procedure-part shall not appear.
Delete the phrase "type parameters and" from line 8 of
page 47.
SUBMITTED BY: Robert Corbett
HISTORY: 08-nnn m185 F03/nnnn Submitted
<submit the proposed interp as a meeting paper yy-nnn for the next
J3 meeting mxxx>
More information about the J3
mailing list