08-261
To: J3
From: Michael Ingrassia
Subject: Interp: When are parameterized sequence types the same type?
Date: 2008 July 28
Bob Corbett asked a number of questions that I think
need consideration by the committee. Rather than split these
questions up into separate interp requests (which the Interp
committee is free to do), I have numbered them
and interleaved the questions with the motivating discussions,
which I have labeled as DISCUSSION so that the proposed ANSWER
will stand out.
There are approximately 5 questions in all, in two separate
QUESTION sections, with comments in two separate DISCUSSION
sections, and I have have supplied
a single proposed answer that covers all of them.
NUMBER: F03/XXXX
TITLE: When are parameterized sequence types the same type?
KEYWORDS: type parameter, sequence type
DEFECT TYPE: Erratum
STATUS:
QUESTION:
(1) 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) ?
(2) How complicated can the expressions a processor must
determine are equal or different be?
DISCUSSION:
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.
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 :: N
SEQUENCE
REAL A(N+N)
END TYPE
TYPE(T(M)) :: X
END SUBROUTINE
END INTERFACE
TYPE T(N)
INTEGER :: 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 :: N
SEQUENCE
REAL A(2*N)
END TYPE
TYPE(T(M)) :: X
END SUBROUTINE
END INTERFACE
TYPE T(N)
INTEGER :: 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 2003 standard
require a conforming processor to detect and report
the conflict with the rules given in 16.2.3? 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) :: N
SEQUENCE
REAL A(N+N)
END TYPE
END
MODULE M2
TYPE T(N)
INTEGER(KIND=4) :: 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.
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.1.3.
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 04-007:
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-XXX m185 Submitted