(j3.2006) (SC22WG5.3653) [ukfortran] FW: Notes on WG5 coarray papers

[Malcolm Cohen]

I have a couple of obvious comments...

> As a consequence, the object must additionally be a scalar, since the last
> cited sentence would also apply to arrays of the above types. It may be
> necessary to change the wording of 8.5.1, para6 to
>
> "A scalar coarray 
An array is just a collection of scalars.  We've been here before: it is 
not trivial to describe what you seem to be meaning in standardese, and 
might not have the effect you thought you were intending.

I'm not necessarily arguing about what your probable intent is here, but 
you are not going to hit all (or possibly even most) of the problem 
cases just by putting the word "scalar" in this one place.

> the following additional Note is suggested for 8.5.1:
>
> -------------------------------------------------------------------------------
> NOTE 8.29a
> A scalar coarray that is volatile and of type default integer, default real,
> or default logical is 'atomic' in the sense that read accesses from any image
> other than those altering its value will obtain either the value previous to
> an alteration, or the value after an alteration.
>   
Be careful: either there is normative text that obviously supports this 
(in which case the note is probably unnecessary), there is normative 
text but the reasoning to get here is convoluted (in which case an 
explanation would be useful) or there is no normative text (in which 
case the note is wrong - it's not worded as a requirement, and 
requirements are not allowed to appear in notes anyway).

In any case, I find this suggested note wanting.
> Example 2.3 ("Composite object") is non-conforming since the VOLATILE
> coarray is not a scalar and hence the restrictions from 8.5.1 apply.
>   
You mean "would not be conforming if we could somehow word the 
restriction I want".  There is no such restriction in 8.5.1 at present 
that I see.

> Example 2.4 ("Protected Context") is non-conforming since the cited
> restriction is violated by the object in question being VOLATILE within
> the scope of the DO loop. This would apply even if the CASE(1) statements
> were not present.
>   
There is no restriction that says a DO index variable cannot have the 
VOLATILE attribute, and the "cited restriction" does not even mention 
VOLATILE.  So I cannot agree with your reasoning.  (In fact I think the 
example is conforming when used as described in the paper.)
> In section 4 ("Behaviour on Commodity Clusters"), the example with the
> INTEGER, VOLATILE :: table(1000)[*]
> has a high likelihood of being non-conforming since again the object is
> not scalar, and there may be updates coming in from other images in an
> unordered segment.
Au contraire, there are no references to the array table in the example 
code, only to scalar subobjects thereof.  Scalar subobjects of a 
VOLATILE object are themselves VOLATILE.  And scalar.  And thus don't 
even fall foul of the imaginary restriction that is not yet in 8.5.1.

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