(j3.2006) (SC22WG5.5441) Result of WG5 straw ballot 8 on Fortran 2008 interpretations

[John Reid]

WG5,

Here is the result of WG5 straw ballot 8 on Fortran 2008 interpretations.

John.
-------------- next part --------------
                                        ISO/IEC JTC1/SC22/WG5 N2047

         Result of the interpretations ballot 8, N2043
         
Key for the Result line:
     Y vote passes unconditionally.
     C vote passes, subject to minor changes noted below.
     N vote fails. Returned to J3 for further work. 
          
   
           F08/ F08/ F08/ F03/ F08/ F08/ F08/ F08/ F08/ F08/ 
           0099 0100 0101 0102 0103 0104 0106 0108 0112 0113 
Bader        Y    Y    Y    Y    Y    Y    Y    Y    Y    Y
Chen         Y    Y    Y    Y    Y    Y    Y    Y    Y    Y
Cohen        Y    Y    Y    Y    Y    Y    Y    Y    Y    Y
Corbett      Y    Y    Y    Y    C    Y    Y    Y    Y    Y
Long         Y    Y    Y    Y    Y    C    Y    Y    Y    Y
Muxworthy    Y    Y    Y    Y    Y    Y    Y    Y    Y    Y
Reid         Y    Y    Y    Y    Y    C    Y    Y    Y    C
Snyder       C    Y    Y    N    Y    Y    Y    Y    Y    Y
Whitlock     Y    Y    Y    Y    Y    Y    Y    Y    Y    Y
Result       Y    Y    Y    Y    Y    C    Y    Y    Y    C


Comments, reasons for NO votes, and decisions of /INTERP. 

F08/0099   

Snyder comment

  There is no execution sequence for evaluation of specification
  expressions within a <specification-part>.  The only requirement is
  that the specification expressions are evaluated, in processor-
  dependent order, before the first executable construct is executed.

  Therefore, one might infer that the value of a volatile variable
  that appears more than once in specification expressions could be
  required to be copied into an anonymous local variable, and then that
  value used throughout elaboration of the specification part.  The
  answer would thereby be "The program is required to print 'T T'."  A
  note explaining the reasoning by which the program is not required to
  print 'T T' would be helpful:
  "NOTE 7.33a
    If a variable that has the VOLATILE attribute appears more than
    once in a <specification-part>, its value might be different at each
    appearance.  For example, if N has the VOLATILE attribute, the
    specification expressions N*N and N**2 might have different values."
    
Decision of /INTERP: pass unchanged.

Reasons: We disagree that it would be helpful to put in a Note in the 
middle of "expressions" in clause 7 to explain the semantics of VOLATILE, 
which are adequately described in the "VOLATILE attribute" subclause of 
clause 5. 

F08/0102  

Snyder reason for no vote

  I agree with the analysis and answer, but not the edit.

  Three lines into the proposed new paragraph, it says "(for both the
  declared and dynamic types)".  Upon arriving at that statement, one
  wonders "Where does it say that?"  One might expect that a statement
  prefaced with "Because..." ought to have prior supporting normative
  specification.  The only places that "dynamic" appears in Clause 13
  are in the descriptions of EXTENDS_TYPE_OF, MOVE_ALLOC, SAME_TYPE_AS,
  and STORAGE_SIZE.  The note in the answer shows why it is necessary,
  but the reader ought not be required to prove this theorem.

  Insert "declared and dynamic" before "type and type parameters" at
  [368:24], and in the edit for [368:26].

  Further, it does not follow that the result is polymorphic if and only
  if TSOURCE and FSOURCE are polymorphic, simply because they are
  required to have the same declared and dynamic type and type
  parameters.  Remove "Because ... types)," from the edit (and
  capitalize "the"), leaving only the requirement (not the unsupported
  conclusion) "The result is polymorphic if and only if both TSOURCE and
  FSOURCE are polymorphic."
  
Decision of /INTERP: pass unchanged. 

Reasons: 
The requirement on the type of TSOURCE being the same as the type of 
FSOURCE (at [368:24]) is not qualified explicitly or implicitly to be 
referring to one or the other, therefore this must mean both the 
declared type and the dynamic type, see interp F08/0047. 

It does follow that the result is polymorphic if and only if TSOURCE 
and FSOURCE are polymorphic. If TSOURCE is not polymorphic, the result 
has its dynamic type and so is not polymorphic. If FSOURCE is not 
polymorphic, TSOURCE has the dynamic type of FSOURCE and so the result
does too and is therefore not polymorphic. 

F08/0103

Corbett comment:

The answer given requires processors to use less efficient implementations
of procedure pointers that target internal procedures and actual arguments
that are internal procedures than is necessary.  Allowing the two
argument form of the intrinsic function ASSOCIATED to take procedure
arguments effectively banned some optimizations, but at least a case
can be made for doing so.  Requiring ASSOCIATED to return .FALSE. in the
case where the arguments ultimately reference different instances of the
same internal procedure prohibits a processor from taking advantage of the
special case where the internal procedure references only statically
allocated variables in the host scoping unit.  I cannot think of a case
where such semantics are useful.  If the answer had been that the result
returned by ASSOCIATED is undefined when both arguments reference the same
internal procedure, more efficient implementations would be possible.

Nonetheless, I do not oppose the interpretation.  The new semantics given by
the interpretation should at least be implementable for processors where
pointers to internal procedures are allowed.

Decision of /INTERP: pass unchanged. 

Reasons: Different people preferred different answers. The current answer 
was the only one with overall support.

....................................................................

F08/0104

Long comment:

The edit instruction "[407-408:24+]" seems irregular.  Table
14.1 starts at [407:24+], but the change is on page 408.  [408:1-]
would be better.

Reid comments:

1. The wording of the edit for [150:28+] is awkward and suggests
that the clause "where each argument is a restricted expression,"
applies only to a function from the intrinsic module ISO_C_BINDING.
The wording should be like that proposed for [152:7-8]. I suggest:

"(nn) a reference to a transformational function from the intrinsic 
module IEEE_ARITHMETIC (14), IEEE_EXCEPTIONS (14), or ISO_C_BINDING 
(15.2), where each argument is a restricted expression,"

2. The edit labelled for [407-408:24+] should be labelled for
[408:1-].

Decision of /INTERP: pass as amended. 

....................................................................

F08/0113

Reid comment:

In the last line of the edit for [194:6-] add "the value of" before
"<lock-variable>". 

Decision of /INTERP: pass as amended.