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