(j3.2006) (SC22WG5.5434) WG5 straw ballot 8 on Fortran 2008 interpretations

[John Reid]

WG5,

Here is a first provisional result of the straw ballot 8 on Fortran 2008 
interpretations. Have I included your votes correctly? Have I missed any?

We have comments only this time. I will discuss responses with /INTERP.

Cheers,

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

         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
Result       Y    Y    Y    Y    ?    ?    Y    Y    Y    ?


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

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: 

Reasons: 

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

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: 

Reasons: 

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

F08/0113

Reid comment:

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

Decision of /INTERP: 

Reasons: 

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