(j3.2006) (SC22WG5.5255) [ukfortran] FW: J3 Fortran interp letter ballot #30- due 13-Jun-2014

[Malcolm Cohen]

Not a vote, but my opinions nonetheless...

The following Fortran interpretations are being balloted:

Yes  No   Number     Title

-Y-  ---  F08/0099   VOLATILE in specification expressions
-Y-  ---  F08/0100   IMPORT statement and prior explicit declaration
-Y-  ---  F08/0101   NAMELIST and multiple occurrences of a variable
-C-  ---  F08/0102   MERGE and polymorphism
-C-  ---  F08/0103   Pointers to internal procedures with different host
                                instances
-C-  ---  F08/0104   IEEE Inquiry Functions
---  -N-  F08/0105   Is the ASYNCHRONOUS attribute allowed with the
                                VALUE attribute?
-Y-  ---  F08/0106   MOVE_ALLOC for a remote array


COMMENT on F08/0102:
I think it is clear that (E) is polymorphic.  Being polymorphic is not something 
that depends on a runtime value or a dynamic type; the statement (E) is only 
not-standard-conforming if it is actually executed with Y and X having different 
dynamic types.  We could fix the example (add a new allocatable W, and W=t2(), 
and change example E to do a merge between Y and W instead of Y and X) but it 
doesn't seem particularly important.

COMMENT on F08/0103:
The current answer (the "right answer") is the only one that is at all useful to 
the user IMO.  The optimisability of internal procedures *as actual arguments* 
when they only reference SAVEd variables (i.e. they are not thread-safe) is the 
wrong concern.  The whole point of passing an internal procedure as an actual 
argument is to enable stuff like thread-safety otherwise the user can just pass 
a module procedure instead.

Anyway, we took this straw vote, including both the options of making 
ASSOCIATED(x,y) when they refer to the "same" internal procedure either 
processor-dependent or prohibited.  That straw vote was 5-1-1-1-1 (right 
answer - wrong answer - processor dependent - prohibited - undecided).  If we're 
going to retake it, not that I think we should, I would prefer the current 
answer.

NO vote on F08/0105:
ASYNCHRONOUS dummy arguments have a bunch of constraints that, and I quote
   "are designed to avoid forcing a processor to use the so-called 
copy-in/copy-out argument passing mechanism"
As currently written that is not true for ASYNCHRONOUS+VALUE because VALUE 
forces the copy-in part of that mechanism.  Furthermore, those restrictions 
(C1238 to C1240) do not make sense for ASYNCHRONOUS+VALUE because the dummy is 
not associated with the actual argument but with a copy thereof.  We fixed this 
for VOLATILE by prohibiting it to be combined with VALUE.  That is by far the 
easiest and most sensible fix for ASYNCHRONOUS.   Alternatively, rewrite those 
constraints to make sense e.g. "with/has the ASYNCHRONOUS" -> 
"without/does-not-have the VALUE attribute and with/has the ASYNCHRONOUS" 
several times, and fix the NOTE so it is not "at best misleading".

Cheers,
-- 
................................Malcolm Cohen, Nihon NAG, Tokyo.