(j3.2006) FW: 11-229 J3 Fortran interp letter ballot #24 - due 19-Aug-2011 - 2nd try

[Bill Long]

Vote from Bill Long, Cray Inc. :


The following Fortran interpretations are being balloted:

Yes  No   Number     Title

-Y-  ---  F03/0017   Dummy procedure pointers and PRESENT
-C-  ---  F03/0018   Multiple identical specific procedures in
                       type-bound generic
-Y-  ---  F03/0019   Multiple identical specific procedures in
                       generic interface blocks
-Y-  ---  F03/0021   What kind of token is a stop code?
-Y-  ---  F03/0046   Unlimited polymorphic pointers in common blocks
-Y-  ---  F03/0053   The BIND attribute for C_PTR and C_FUNPTR
-Y-  ---  F03/0065   Relational equivalence
-Y-  ---  F03/0084   IEEE_SET_ROUNDING_MODE in a subroutine
-C-  ---  F03/0103   Restrictions on dummy arguments not present for
                       polymorphic type or parameterized derived type
-Y-  ---  F03/0116   indistinguishable specifics for a generic
                       interface with use association
-Y-  ---  F03/0118   Are lower bounds of assumed-shape arrays assumed?
-C-  ---  F03/0120   When are parameterized sequence types the same type?
-Y-  ---  F08/0055   G editing for reals
-Y-  ---  F08/0056   Non-polymorphic ALLOCATE with polymorphic SOURCE=
-Y-  ---  F08/0057   Interoperability with empty types
-Y-  ---  F08/0058   ENTRY point RESULT variable
-Y-  ---  F08/0059   Auto-targetting requirements
-Y-  ---  F08/0060   Procedure pointer assignment with an EXTERNAL target
-Y-  ---  F08/0061   Description of the CONTIGUOUS attribute misworded?
-Y-  ---  F08/0062   Mixing default initialization with DATA
                       initialization

Comment for F03/0018:
--------------------------------

The answer says that the two specifics for the generic are "ambiguous". 
  They are actually the same routine (MyAdd), which is still a violation 
but just of a different rule.  The ultimate conclusion (code is not 
conforming) is still accurate, but the reasoning can be improved.

Note: This does raise an interesting question - for the case that the 
two specific procedures are actually the same procedure, it is not 
really ambiguous in the sense that either path leads to the same code. 
In a future revision, we could explore relaxing this restriction.

Comment for F03/0103:
--------------------------------

The second line of the program text for Q2 is

    Integer,Length :: n

which is incorrect syntax.  It should be

   Integer,Len :: n


Comment for F03/0120:
--------------------------------

In the program text for part (5) the following code sequence occurs 4 times:

    TYPE T(N)
      INTEGER :: N
      SEQUENCE

with the implication that INTEGER :: N declares a type parameter, since 
it appears before the SEQUENCE statement.   But this is not valid 
syntax.  The LEN or KIND attribute is  required here.  A reasonable 
repair would be

     TYPE T(N)
       INTEGER,LEN :: N
       SEQUENCE

Similarly, the subsequent example contains, twice:

     TYPE T(N)
        INTEGER(KIND=4) :: N
        SEQUENCE

which could be repaired as:

     TYPE T(N)
        INTEGER(KIND=4),LEN :: N
        SEQUENCE

Finally, the text of the subsequent subroutine S contains:

       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

which seems baffling. With the type T from each of the modules renamed 
to T1 and T2 locally, there is no type named T visible here.  Yet the 
declarations of X and Y both use type T(N).  The compiler was displeased.

I think the following alternative demonstrates what was intended (and 
also seems to compile and execute as one might expect):

        MODULE M1
          TYPE T(N)
            INTEGER(KIND=4),LEN :: N
            SEQUENCE
            REAL A(2*N)
          END TYPE
        END

        MODULE M2
          TYPE U(N)
            INTEGER(KIND=4),LEN :: N
            SEQUENCE
            REAL A(N+N)
          END TYPE
        END

        program main
          read *, N
          call test(n)
        end program main

        subroutine test(n)
          use m1
          type(t(n)) :: x,y
          x = t(n)([ (real(i),i=1,2*n)])
          call sub(x,y,n)
          print *, y
        end subroutine test

        subroutine sub(x,y,n)
          use m2
          type(u(n)) :: x,y
          y = x
        end subroutine sub


------End of comments--------




-- 
Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101