(j3.2006) (SC22WG5.4522) Second WG5 ballot on interpretations

[Bill Long]

On 9/7/11 4:11 AM, John Reid wrote:
> WG5,
>
> Here is the ballot on the second half of the interpretations that are ready.
> This will end at 0900 UK time on Wednesday, 5 October. May I remind you that the
> first ballot (N1876) will end at 0900 UK time on Thursday, 22 September?
>
> Thanks,
>
> John.
>

Ballot votes from Bill Long (Cray Inc.):

The following Fortran 2003 interpretations are being balloted:

Yes  No Number     Title
-Y- --- F08/0021   STORAGE_SIZE and unlimited polymorphic
-Y- --- F08/0022   DO CONCURRENT and file i/o
-Y- --- F08/0023   DO CONCURRENT and POINTER
-Y- --- F08/0024   Dummy arguments of impure elemental procedures
-Y- --- F08/0025   DO CONCURRENT and ALLOCATABLE
--- -N- F08/0026   DO CONCURRENT and output interleaving
-Y- --- F08/0027   ATOMIC_REF example
-Y- --- F08/0028   Does a procedure reference cause loop termination?
-Y- --- F08/0029   G0 edit descriptor and floating-point output
-Y- --- F08/0030   Unlimited format repeat effects
--- -N- F08/0031   PURE INTENT(OUT) finalization
-C- --- F08/0032   PURE FUNCTION result finalization
-Y- --- F08/0033   PURE polymorphic finalization
-Y- --- F08/0034   ELEMENTAL INTENT(OUT) finalization
-Y- --- F08/0035   Maximum value for SHIFT argument to SHIFTL
                    and SHIFTR
-Y- --- F08/0036   NORM2 example in Annex C
-Y- --- F08/0037   PROCEDURE POINTER vs PROTECTED
--- -N- F08/0038   Are pointless restrictions on DIM arguments
                    intended?
-Y- --- F08/0039   Many-one vector subscript usage
-Y- --- F08/0040   MOVE_ALLOC for coarrays
--- -N- F08/0042   SOURCE= questions
-Y- --- F08/0043   Executing a type-bound procedure on a coindexed
                    object
-Y- --- F08/0044   Resolving the type of a coarray or coindexed object
-Y- --- F08/0046   VALUE attribute restrictions
-Y- --- F08/0047   public generic with same name as private type
-Y- --- F08/0049   ELEMENTAL functions with nonconstant type parameters
-Y- --- F08/0050   Ordering requirements on definition of specification
                    functions
-Y- --- F08/0051   Pure procedure arguments with VALUE
-Y- --- F08/0052   Private type-bound procedures
-Y- --- F08/0053   Restrictions on generic declarations, generic
                    resolution
-C- --- F08/0054   Requirements for needing an explicit interface


Reasons for Comments and No votes:

F08/0026:

The example for Q1 shows output in the other order from what would occur 
for sequential execution of the loop. Q1 asks if allowing this was 
intentional.  A1 says No, it was not intentional.  Yet, the edit 
supplied says that the output is, in fact, allowed.  I think that the 
answer A1 should be Yes.  The edit is still desirable as a response to 
Q2/A2.

F08/0031:

The proposed constraint requires that the INTENT(OUT) attribute on the 
dummy argument be visible to the code that would perform the 
finalization.  This requires that the "as a matter of practicality" 
condition in the second paragraph of the DISCUSSION in fact always be 
true.  This seems a bit weak for a constraint in the standard.  A 
non-constraint would be better.

I also found the wording of the proposed constraint, "shall not be such 
that..." unnecessarily vague.  Something more direct would seem 
preferred, such as

"The type of an INTENT(OUT) argument of a pure procedure shall not 
specify an impure final subroutine."

F08/0032:

I found the wording of the proposed constraint, "shall not be such 
that..." unnecessarily vague. Something more direct would seem 
preferred, such as

"The type of the result value of a pure function shall not specify an 
impure final subroutine."

F08/0038:

The text in 13.2.4, on which the subsequent edits depend, relies on a 
poorly defined concept of "reduction".   In particular, some of the 
"reductions" that are cited in the edits are not what people normally 
think of as reductions (i.e. ones that return a result that is the same 
type as the input).   It might be better in 13.2.4 to refer to 
Transformational functions that have a DIM argument.  That is 
unambiguous.  It would also cover the cases that currently would not be 
considered "reductions": FINDLOC, MAXLOC, MINLOC, ALL, ANY, PARITY, and 
THIS_IMAGE.

Also, the COUNT intrinsic [338:31] seems to be missing from the list. 
Seems like an oversight.

F08/0042:

The example for Q2:

  program example2
  real,allocatable :: x[:]
  allocate(x)
  x = 3
  end

says that it does not conform to the standard because of 6.7.1.1p4. 
This is irrelevant. It fails to conform to the standard because it 
violates C634.  The allocate statement is required to be

   allocate(x[*])

at which point there is no SOURCE= issue involved.  At a minimum, the 
example needs to be replaced with one that illustrates something related 
to SOURCE=.

F08/0054:

This proposes a fix to something that is broken in both F2003 and F2008. 
  Since the change is only in F2008, it then a change from F2003 that 
should be listed in 1.6.2?

Cheers,
Bill

-- 
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