(j3.2006) (SC22WG5.5368) J3/14-279: J3 Fortran interp letter ballot #32 revised - due 9-Jan-2015

[Bill Long]

Ballot from Bill Long for Cray Inc:


 
Yes  No   Number    Title
 
Y--  ---  F08/0105  Is the ASYNCHRONOUS attribute allowed with the
                     VALUE attribute?
---  -N-  F08/0110  Interdependence of specifier values in input/output
                     statements
-Y-  ---  F08/0115  ASYNCHRONOUS and argument passing
-Y-  ---  F08/0116  Interoperable procedures
-Y-  ---  F08/0117  TARGET and coindexed arguments
-Y-  ---  F08/0118  Subobject of variable in variable definition context
-Y-  ---  F08/0119  Branching to END BLOCK and END CRITICAL
-Y-  ---  F08/0120  Is the name of a procedure pointer a local identifier?
-C-  ---  F08/0121  Add to introduction defined operations in
                     specification exprs
-Y-  ---  F08/0122  Types with coarray components
-C-  ---  F08/0123  SPACING intrinsic
-C-  ---  F08/0124  Coindexed object with polymorphic subcomponent
 

For F08/0110:
-------------

I agree with the intent of the answer, but I think the edits say
things we don't intend. In particular, "affected by [the] data
transfer" is too broad.

In the [243:3-5] edit we are saying that the value of the SIZE=
specifier cannot "be affected by data transfer caused by that
statement".  This is certainly not true.  The data transfer
*determines* the value.

The [243:6-7] edit implies that the statement

  read (*,*) I, A(I)

is not conforming, since the denotation of A(I) depends on the value
of I which certainly is "affected by the data transfer". Yet this sort
of thing appears all over in existing codes.


For F08/0121:
-------------

The edit says more than is actually true. Not any <defined-operator>
is allowed in a specification expression.  This could be fixed by
changing the edit to "A <defined-operator> defined by a specification
function may be used in a specification expression."


For F08/0123:
-------------

I would like to see the resolution of Robert Corbett's comment on this
interp. The interp he mentioned, F03/0055, appears to have passed and
was included in Corrigendum 1 of F2003. 


For F08/0124:
-------------

While I agree there is a defect that needs attention, the proposed
"potential subobject component" term is awkward at best, and has a
recursive definition.  And the resulting constraint would end "has a
polymorphic allocatable potential subobject component". Not an example
of clarity.  And it appears to say "allocatable nonpointer" which is
automatically true, since allocatable and pointer are mutually
exclusive.  







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