(j3.2006) (SC22WG5.5061) [WG5 letter ballot 6 on Fortran 2008 interpretations]

[Van Snyder]

                                             ISO/IEC JTC1/SC22/WG5 N1988

          WG5 letter ballot 6 on Fortran 2008 interpretations
                      John Reid, 4 August 2013

This is the sixth WG5 vote on a set of draft interpretations for
Fortran 

2008. They have all been approved in a J3 letter ballot.  

The following Fortran 2008 interpretations are being balloted:

Yes  No Number     Title

-Y-  ---  F03/0030   IEEE divide by zero
-Y-  ---  F03/0047   Polymorphic arguments to intrinsic procedures
-Y-  ---  F03/0053   The BIND attribute for C_PTR and C_FUNPTR
-Y-  ---  F03/0064   Recursive declaration of procedure interfaces
-Y-  ---  F03/0100   Error in field width for special cases of signed
                     INFINITY output
---  -N-  F03/0139   Functions returning procedure pointers

                     In the edit for [278:11], "... function result if
                     it is a function" seems a bit redundant.  Would
                     "... function result" be good enough?  If the
                     procedure is a subroutine, it can't have a
                     function result.

                     In the edit for [310:5-6], the term "result
                     names" is used.  In other edits, the term
                     "function result" is used instead of simply
                     "result".  Should "result names" here be "function
                     result names", for consistency?

                     [310:6-7] appears to imply that a function
                     subprogram cannot define two functions that have
                     procedure pointer results with different
                     characteristics, or some that have procedure
                     pointer results and others that have data object
                     results (because a procedure pointer cannot be
                     storage associated with another one, or with a
                     variable).

                     This ought to be clarified or repaired.

                     If these are considered to be fodder for a different
                     interpretation request, rather than further work
                     necessary for the present one, this mark on my ballot
                     can be changed to "yes with comment."

                     The edit for [170:23+] could more economically combine
                     the requirement with C804: "<expr> shall not be a
                     variable or a function reference that returns a
                     procedure pointer."

-Y-  ---  F08/0071   Vector subscript target
-Y-  ---  F08/0075   Pointer function reference as variable in assignment
-Y-  ---  F08/0076   Pointer function reference in READ
                     Subsumed by F07/0075
-Y-  ---  F08/0083   Type parameter default expressions allow circular
                     dependence
-Y-  ---  F08/0084   Pointer arguments to PURE functions
-Y-  ---  F08/0085   Problems with PARAMETERs
-C-  ---  F08/0086   Implied-shape and separate PARAMETER statement

                     For the archive, in the question, replace "conforms
                     to Fortran 77 to Fortran 2008" with something like
                     "conforms to Fortran 77 through Fortran 2008" or
                     "conforms to all Fortran standards from 2007 to 2008".

-Y-  ---  F08/0087   Mixed-kind character assignment
-Y-  ---  F08/0088   Can ALLOCATE with SOURCE= have side-effects in a
                     PURE proc?
-C-  ---  F08/0089   Variable-denoting functions change existing
                     semantics

                     The term "pointer function" is not used as a noun,
                     although "nonpointer function" is so used at [454:36].
                     I have a slight preference that "pointer function" in
                     the edit for [24:11+] be replaced by "function that
                     returns a pointer result" in both paragraphs.  The
                     same change ought to be made in the edits for [24:27+]
                     and [25:6+]

                     A parallel change ought to be made at [454:36], but
                     that can be done editorially rather than within this
                     interpretration.

---  -N-  F08/0090   What restrictions apply to initialization and
                     PARAMETER?

                     One might argue that type, type parameters, and
                     shape are covered by 5.2.3p1.  In the examples,
                     the <constant-expr> cannot be "converted according
                     to the rules for intrinsic assignment."  Since this
                     is impossible, no interpretation is established, and
                     the examples are not conformant, and therefore no
                     edits are needed.

                     On the other hand, the description of the conversion
                     in 5.2.3p1 needs to have some attention to cover the
                     implied-shape case.

The text of these interpretations is in N1987.  Each interpretation
starts there with a row of "-"s.

Please mark the above -Y- in the Yes column for "yes", -C- in the Yes
column for "yes with comment", or -N- in the No column for a "no"
answer {be sure to include your reasons with "no"} and send to

        sc22wg5 at open-std.org

by 0900 UK time on Monday, 2 September 2013, in order to be counted.

Thanks,

John.