(j3.2006) (SC22WG5.4839) [ukfortran] WG5 letter ballot 5 on Fortran 2008 interpretations

[Malcolm Cohen]

Nick Maclaren writes:
>F08/0040
>
>I am not convinced about the last sentence of the proposed addition to
>[372:29+] 13.7.118, p6+, because my understanding is that it is not
>actually required to be a barrier-type synchronisation.  Would "may be"
>be better than "is"?

Short answer: No.

Longer answer: I think this needs to be the same kind of synchronisation as 
ALLOCATE, see 6.7.1.2p4 which contains essentially identical wording (but for 
ALLOCATE rather than MOVE_ALLOC).

Therefore I think this should pass as is.

Van Snyder writes re F08/0080:
>I agree with the conclusions, but 7.2.1.3p13 together with 4.8p3 don't
>quite make the answer to Q1 work.   An additional edit at [85:18] is
>needed: Insert "type and" before "type parameters". I think this is
>also needed for an array constructor of the form [ real :: 3, 1.5 ].

I think I would have to agree with this.  The intrinsic type case is clearly 
intended to work otherwise we would not have worded C4104 the way that we did.

I don't however think that this is a fatal flaw in this interp, though we should 
certainly fix it sometime.

So my vote is

Yes  No   Number     Title

-C-  ---  F08/0040   MOVE_ALLOC for coarrays
-Y-  ---  F08/0074   Implicit type in BLOCK construct
-Y-  ---  F08/0077   Function references as variables in DATA statements
-Y-  ---  F08/0078   Are the IEEE values +0 and -0 distinguished
-Y-  ---  F08/0079   NAMELIST and type specification
-C-  ---  F08/0080   Array constructors with polymorphic values
-Y-  ---  F08/0081   Deallocation error handling
-Y-  ---  F08/0082   Generic identifier and dtv arguments

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