(j3.2006) co-array variable

[Aleksandar Donev]

On Friday 25 May 2007 15:04, Bill Long wrote:

> The original intent of [197:13-15] (the result of considerable discussion
> and compromise) was to not allow array elements or structure components in
> this context.
After some discussion with Bill (I think) we've concluded that there was no 
such intent---the point of scalar is to restrict to atomic references and 
array elements and structure components seem not that different from scalar 
co-arrays (but maybe someone can again explain to me why array elements are 
not allowed as DO indices?).

Consider:

LOGICAL, VOLATILE :: LOCKS(10)[*]

The intent is that

IF(LOCKS(1)) ...

may be unordered with respect to the definition of LOCKS by other images. 
However, the references:

IF(LOCK(1)[1]) ...
IF(ALL(LOCKS)) ...

must precede or follow the corresponding definitions by other images. The 
first one has a co-indexed reference and the second references a co-array of 
nonzero rank. 

Similarly, I believe

IF(CheckFlag(volatile_co_array_of_some_type))

should require segment ordering, but

IF(volatile_co_array_of_some_type%logical_flag)

should not.

This is all weird, but such is VOLATILE. Allowing non-atomic unordered 
references to VOLATILEs would lead to even more weirdness if not plainly 
contradictory semantics.

Granted, one can say ALL(volatile_array) already in Fortran 2003 and different 
elements of volatile_array may change at different times (externally) and 
lead to weirdness, but then this is outside the standard. Since co-arrays are 
built-in they should have well-defined semantics even in the presence of 
weird attributes.

Aleks

-- 
Aleksandar Donev, Ph.D.
Lawrence Postdoctoral Fellow @ LLNL
High Performance Computational Materials Science and Chemistry
E-mail: donev1 at llnl.gov
Phone: (925) 424-6816  Fax: (925) 423-0785
Address: P.O.Box 808, L-367, Livermore, CA 94551-9900
Web: http://cherrypit.princeton.edu/donev