(j3.2006) derived types with type parameters are different

[Robert Corbett]

Bill Long wrote:
> 
> Andy Vaught wrote:
> 
>>On Tue, 29 Jul 2008, Aleksandar Donev wrote:
>>
>>  
>>
>>>On Tuesday 29 July 2008 13:46, Michael Ingrassia wrote:
>>>    
>>>
>>>>If it causes significant loss of functionality, what exactly is the
>>>>functionality that we lose?
>>>>      
>>
>>  
>>
>>>I (and probably Lawrie andothers) agree, but there is the issue of backward 
>>>compatibility and simply not making "language design" changes 
>>>retroactively---only fixes of techical messups.
>>>    
>>
>>  You're worried about backwards compatibility on a feature that few
>>compilers have implemented.  
> 
> 
> I think the issue here is the basic integrity of the standards process.  
> If we take the attitude that, 5 years after the fact, it's OK to remove 
> some intentionally included feature from the standard because vendor X 
> thinks it is a lot of work, then what level of confidence does any 
> vendor have in the stability of the standard?

My reason for wanting to drop the feature is not that implementing it is
a lot of work.  My reason for wanting to drop the feature is that it is
poorly defined.  My first impulse was to recommend that one of the
simple definitions of equivalence be adopted.  For the sake of the
vendors who had already implemented the feature, I decided that the
standard should leave what it means for parameterized sequence types
undefined.  The simplest way to achieve that effect is to drop the
feature from the standard.  Vendors who wanted to provide the feature
could still provide it, but users would understand that their codes
that use the feature are unlikely to be portable.

> Are they supposed to 
> guess what is "real" and what is just "maybe"?    Why would any vendors 
> take the standard seriously?  At which point the whole purpose of the 
> standard is defeated.
> 
>>Surely, very few people are today depending
>>on parametrized derived types 
> 
> 
> Surely at some point very few people depend on any new feature.  Hardly 
> an argument for removal.

A feature that few people are depending on four years after the standard
was approved could be considered questionable.

Adding and deleting features from the standard via interpretations is
hardly unprecedented.  In Fortran 95, the ability to execute a STOP
statement from a function called from an input/output list was dropped
as a result of an interpretation.  In Fortran 2003, a slightly altered
version of that capability is about to be added via an interpretation.

>>and even fewer are further depending on the
>>compiler to figure out that n+n is the same as 2*n in a sequence type.
> 
> I've though about the example case more, and I think the IBM compiler is 
> right.  The issue with disambiguation is in comparing the types of the 
> dummy arguments, not the definitions of the types.  The declarations of 
> the dummy arguments include a literal constant (2) for the value of N, 
> so in both cases it is clear that the array declaration is A(4).   Two 
> compilers not agreeing is no cause for a national emergency.  We can fix 
> our compiler.  And thank Bob for the new test case.

You're welcome.  Since I am feeling generous, here is another test case
for you.

---------------------------------------------------------------------------

       MODULE M1
         INTERFACE S
           SUBROUTINE S1(X)
             TYPE T(N)
               INTEGER, KIND :: N
               SEQUENCE
               REAL A(N+N)
             END TYPE
             TYPE(T(2)) :: X
           END SUBROUTINE
         END INTERFACE
         TYPE T(N)
           INTEGER, KIND :: N
           SEQUENCE
           REAL A(N+N)
         END TYPE
         TYPE(T(2)) :: X
       END

       MODULE M2
         INTERFACE S
           SUBROUTINE S2(X)
             TYPE T(N)
               INTEGER, KIND :: N
               SEQUENCE
               REAL A(N*N)
             END TYPE
             TYPE(T(2)) :: X
           END SUBROUTINE
         END INTERFACE
         TYPE T(N)
           INTEGER, KIND :: N
           SEQUENCE
           REAL A(N*N)
         END TYPE
         TYPE(T(2)) :: X
       END

       SUBROUTINE S1(X)
         TYPE T(N)
           INTEGER, KIND :: N
           SEQUENCE
           REAL A(N+N)
         END TYPE
         TYPE(T(2)) :: X
         PRINT *, 'CALLED S1'
       END

       SUBROUTINE S2(X)
         TYPE T(N)
           INTEGER, KIND :: N
           SEQUENCE
           REAL A(N*N)
         END TYPE
         TYPE(T(2)) :: X
         PRINT *, 'CALLED S2'
       END

       PROGRAM MAIN
         USE M1, ONLY: S, X
         USE M2, ONLY: S, Y=>X
         CALL S(X)
         CALL S(Y)
       END

-----------------------------------------------------------------------------------