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

[Bill Long]

The following Fortran 2008 interpretations are being balloted:

Yes  No Number     Title

-Y-  ---  F03/0030   IEEE divide by zero
-C-  ---  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
-C-  ---  F03/0139   Functions returning procedure pointers
-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
-Y-  ---  F08/0086   Implied-shape and separate PARAMETER statement
-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
-Y-  ---  F08/0090   What restrictions apply to initialization and
                      PARAMETER?


Comments:

F03/0047: Answer 5 introduces a curious asymmetry if FSOURCE is not
           polymorphic and TSOURCE is polymorphic. In that case the
           result is polymorphic.  However, the reference could just as
           easily been written merge(fsource, tsource, .not.mask) in
           which case the result is not polymorphic.

           Question 12(b) is really two questions, but there is only
           one Answer 12(b). [I realize that there is a clear pattern
           from previous answers, but this is a formal reply.]

  	  Question 13(d) is really two questions, but there is only
  	  one Answer 14(b).

F03/0139: Several of the edits change "result value" to "function
           result". I would expect the new "function result" text to be
           a hot link to the definition, as was the case with the
           replaced "result value".

	  5.1p2 seems to need more work that the edit for [87:9]. The
	  wording about functions having type and rank is tied to them
	  returning a data result.  This is not relevant for a
	  function that returns a procedure pointer that is associated
	  with a subroutine. Perhaps fixed by adding "that returns a
	  data result" after "A function" in [87:8].

	  Missed a "result variable" that crossed lines [307:16-17].

	  From the edit to C1290 [314:3] I assume that an elemental
	  function is not allowed to return a procedure
	  pointer. Should the initial answer (1b) start "Yes, a
	  nonelemental function..."?

	  In the edit for [433:7] I think the new text would be better
	  as "result is a scalar variable". We are not proposing to
	  allow a Fortran procedure pointer result here.

F08/0089: Twice in the edits appears "...a <function-reference> to a
           pointer function is regarded as a variable...". Should this
           be a "data pointer function"?


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