(j3.2006) J3 Fortran interp letter ballot #22 - due 19-Nov-2010

[Van Snyder]

On Thu, 2010-10-14 at 17:07 -0700, Whitlock, Stan wrote:
>                                                            10-254
...
> The following Fortran interpretations are being balloted:

> Yes  No   Number     Title
 
-C-  ---  F03/0030   IEEE divide by zero
          Change "not true" to "false" because "not true"
          includes "undefined".  This leaves the program non-conforming
          (presumably because the processor is defective) if the result
          is undefined.
          After [403:10-11] insert "14.3p1, second bullet"
          After [462:24+] insert "A.2p1"
-C-  ---  F03/0048   Control edit descriptors in UDDTIO
          Change reference in the question to 9.6.4.8p26
          In edits for [227:15], replace "section 9.6.4.8, in"
          by "9.6.4.8p25," or insert ", 25th paragraph," after "9.6.4.8"
          In edits for [227:17] and [227:18], replace "section 9.6.4.8"
          by "9.6.4.8p26" or insert ", 26th paragraph" after "9.6.4.8"
          In edits for [487:28] maybe replace "section C.6.2, first
          paragraph" by "C.6.2p1".
-Y-  ---  F03/0085   Finalizing targets of pointer or allocatable
                      actual arguments
-Y-  ---  F03/0091   Array components cannot depend on length type
                      parameters
-C-  ---  F03/0096   Can a read statement change the unit value?
          In the ANSWER, change "n the specifier" to "in the specifier".
-C-  ---  F03/0105   SIZE= specifier and UDDTIO
          In the Discussion, change "9.5.1.14 [191:21-26]" to
          "9.6.2.15 [216:32-36]".  Change "using list-directed" to
          "using a list-directed"
-C-  ---  F03/0110   Error in field width for special cases of signed
                      INFINITY output
          Change the title here to "Restoring dropped restriction on
          ENTRY"
-C-  ---  F03/0121   Precise FP semantics of the REAL intrinsic
          This question keeps coming up, and the committees keep
          avoiding the most useful answer, i.e., the one the submitter
          (that is, a real user with a real problem) always asks for.
          Although the answer correctly interprets the standard, the
          result is to force the programmer to use a mysterious kludge. 
          Hopefully, some future revision of the standard actually will
          require REAL with a KIND argument to produce a result of the
          specified kind, not one of whatever representation the
          processor happens to find handy.
-C-  ---  F03/0123   Implicit typing in derived types
          Does this beg for another interpretation request with
          IMPLICIT NONE in the main program?
---  -N-  F03/0124   definition is poorly defined
          The answer implied by the edits is too restrictive.  It should
          be something like
          "When a component of a structure of numeric sequence type or
          character sequence type becomes defined as a result of
          partially associated objects becoming defined, associated
          components of the same type that are components of an object
          of different type do not become undefined."  (This is ugly and
          will need some polishing, but you get the idea.)
-Y-  ---  F03/0128   Subobjects in namelist output
-Y-  ---  F08/0006   generic resolution with banned argument
                      combinations
-Y-  ---  F08/0040   MOVE_ALLOC for coarrays
---  -N-  F08/0041   Segment ordering rules
          "is defined" is a static concept.  The requirement should
          always have been "becomes defined".  Therefore the edit should
          be to replace "variable is defined" to "variable becomes
          defined or undefined" -- or do we need another interp to
          repair this?
-C-  ---  F08/0042   SOURCE= questions
          To avoid future questions of the type "how many times is ...
          evaluated?" can we specify that the values of specifiers are
          considered to be actual arguments to subroutines, so that the
          execution semantics of CALL statements, i.e., the actual
          arguments are evaluated before the invocation, apply
          everywhere?
-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/0045   constraints on entities of type LOCK_TYPE
-Y-  ---  F08/0046   VALUE attribute restrictions
-Y-  ---  F08/0047   public generic with same name as private type
-Y-  ---  F08/0048   Sequence association for coarrays
-Y-  ---  F08-0049   ELEMENTAL functions with nonconstant type
                      parameters