(j3.2006) J3 Fortran interp letter ballot #13 - due 17-Aug-2007 ** due 6-Aug-2007 if possible **

[Jim Xia]

The following Fortran interpretations are being balloted:
 
Yes   No    Number     Title
 
-Y-   ---   F03/0048   Control edit descriptors in UDDTIO
-Y-   ---   F03/0049   Separators in list-directed output
                        involving UDDTIO
-Y-   ---   F03/0050   Questions about internal files
---   -N-   F03/0051   Repeat specifiers and UDDTIO
---   -N-   F03/0086   Elemental and BIND(C)
-Y-   ---   F03/0087   Entry names as dummy procedure arguments
-C-   ---   F03/0088   Defined operations/assignments and
                        VOLATILE/ASYNCHRONOUS
-Y-   ---   F03/0089   Interoperability of non-BIND derived types
---   -N-   F03/0090   Polymorphic array constructors



----------------------------------------------------------------------------
NO vote on Interp F03/0051

While I agree with the spirit of the interp, the edit seems to have a
problem.  Consider the text in the edit marked between *** below:

    "When the first value of an <r*c> constant is transferred to a list
    item by a list-directed input statement, that input statement shall
    transfer all <r> values of that <r*c> constant ***to list items***
    before causing any child input statement to be invoked.  If that
    list-directed input statement is itself a child input
    statement, it shall transfer all <r> values of that <r*c> constant
    ***to list items*** before terminating."

There may not be enough list items to transfer all <r> values to.  I think
the input statement should transfer as many (up to <r>) values as are
available list items and then ignore (throw away) the rest.

For example, for the program in the interp document:
The first child input statement encounters 2*3. It will transfer a number 
3
to dtv%i. There are no more list items to transfer the second 3 to, so I
believe it should skip the second number 3.

Here is another example, this time with the parent statement:

PROGRAM foo
  USE m
  TYPE(t) :: a
  INTEGER :: i
  OPEN(10, FILE='file.txt', ACCESS='stream', FORM='formatted')
  WRITE(10, '(A)') '2*3 5 6'
  REWIND(10)

  READ(10, *) i, a           !<-- parent READ encounters 2*3
  PRINT *, i, a%i, a%j, ipos
END PROGRAM

The parent statement is the first statement to encounter 2*3. It transfers
3 to i, but cannot transfer the second <c> constant to a list item.  At 
the
beginning of the user-defined procedure, the file should be positioned
just before the number 5 (i.e. the rest of the 2*3 is ignored).
Otherwise, the problem with file position reappears.



----------------------------------------------------------------------------
NO vote on Interp F03/0086

I agree with the conclusion of the interp, but I see one minor issue in 
the
edit.  In F2003 standard, ELEMENTAL is never refered to as an attribute.
Similarly but to a less degree, the term BIND attribute is mostly used for
data objects but only a few places for procedures.  A procedure with "BIND
attribute" is regularly referred to be with <proc-language-binding-spec>.
I'm willing to vote yes if the edit is changed to be consistent with
the rest of the standard.

A proposed edit:

 Replace C1242 in subclause 12.5.2.1 with
 "C1242 (R1227) A procedure shall not be specified with both ELEMENTAL and
 <proc-language-binding-spec>."


----------------------------------------------------------------------------
Comments on Interp F03/0088

Although the edit of this interp is correct, the declaration of the
defined assignment used in the example is invalid.  The declaration 
violates
the rules specified for defined assignment at [263:8-10], which says the
following

        Either the second argument shall be an array whose rank differs 
from
        that of the first argument, the declared types and kind type 
        parameters of the arguments shall not conform as specified in
        Table 7.8, or the first argument shall be of derived type.

Subroutine s declared in the interp can not be used to specify a user 
defined
assignment for rank-one arrays of type real from another rank-one array of 
type
real.

A modified example is suggested as follows:

          INTERFACE ASSIGNMENT(=)
             SUBROUTINE s(a,b)
                 REAL,INTENT(OUT),VOLATILE :: a(1,*)
                 REAL,INTENT(IN) :: b(:)
             END SUBROUTINE
          END
          REAL,POINTER :: p(:,:),q(:)
          ...
          CALL s(p,q)    ! Violation of constraint C1233 [271:9-11],
                         !  associating P with A
          p = q          ! No constraint violation because <actual-arg>
                         !  syntax is not being used



----------------------------------------------------------------------------
NO vote on Interp F03/0090:

Answer (2) of the interp says an array constructor is non-polymorphic
with declared type and dynamic type both of T.  I see at least four
problems with this answer:

1.)  There is no requirement anywhere in the standard for RHS expression
be non-polymorphic in an intrinsic assignment.  The array constructor can
surely be interpreted as a polymorphic array, and the effect is the same
as if a polymorphic pointer/allocatable array appears as the RHS 
expression
in the assignment.  This interpretation will give the same results for the
assignment.

2.)  There are other potential usage of an array constructor containing
polymorphic entities, such as an actual argument to be associated with a
polymorphic dummy array, a selector in ASSOCIATE or SELECT TYPE construct,
a <source-expr> in an ALLOCATE statement for a polymorphic 
pointer/allocatable
array.  It's appropriate to interpret it as a polymorphic array with the
same declared type and dynamic type as those appearing in the array
constructor, respectively.

3.)  This interpretation prohibits use of unlimited polymorphic data in an
array constructor because they don't have a declared type.  There is no
rationale in banning unlimited polymorphic entities in an array 
constructor.

4.)  The same effect of obtaining a non-polymorphic array constructor can
already be achieved by using <type-spec>.







Jim Xia

XL Fortran Compiler Testing
IBM Toronto Lab at 8200 Warden Ave.
Phone (905) 413-3444  Tie-line 969-3444
D2/NAH/8200 /MKM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://j3-fortran.org/pipermail/j3/attachments/20070726/fdb62f84/attachment-0001.html