(j3.2006) a question on cobounds

[Aleksandar Donev]

Malcolm Cohen wrote:

>>> *        integer, save :: U(10)[N,*]      !<-- but do we intend to allow
>>> this?  I have difficulties in finding constraints/rules that forbid this*
>>>
>>>     
>> This is allowed.  The array U has the same size on all images, and the
>> size is known at compile time.  The [N,*] only affects how the image
>> numbers are computed in references within the subroutine. This case is
>> discussed at [92:24-26].
>>   
> Frankly, this looks like shockingly bad design.  Like Jim, I never 
> imagined that something with variable bounds could be static, even if 
> the size were constant.
I did not imagine it either, at first, but I changed my mind after 
reading some of the recent emails (which were as usual a little too 
dramatic for the magnitude of the issue). Modulo real technical problems 
(see BLOCK below), Bill's answer now makes sense to me. Let me explain.

When one declares a variable in a module or top PROGRAM, including a 
coarray, it really is at a "top" or "global" level, and then it makes 
sense to require matching among images. The allocatable coarrays follow 
this model and are IMO consistent even if somewhat unpleasant (i.e., 
even if they appear to try to enforce some programming habits). Now, 
there is no concept of a global subroutine. Even if has a big old SYNC 
ALL at the beginning, it is still just a piece of code executed by a 
single image.

When you declare an array in a subroutine, *even* if it has the save 
attribute, it is my feeling that that array does not sit at a "top" or 
"global" level, rather, it is in some sense local to the routine. In the 
case of coarrays, we have to force the memory footprint to match in 
order to maintain the symmetric heap (we can of course relax that in the 
future for some cases), but it makes no sense to require anything else 
to match: that memory is viewed from the perspective of a particular 
execution of that routine on a particular imagine. I would even argue 
that the lower/upper bounds do not have to be static so long as the 
memory can stay static, but maybe we just found wording that to be too 
complex.

> My followup question is: how can a cobound appear in a derived type 
> definition?
It cannot, at present. It is likely many of these were made to mimic 
some other constraints, without necessarily always doing the full 
elimination. If the Editor feels these should be tightened they can be 
(but later they may be unwound again if we extend something in the future).

> My followup question 2 relates to the text you quoted, which says
>    "If an explicit-coshape coarray has cobounds that are not constant 
> expressions, the cobounds are determined at entry to the procedure ...".
> Well, if the definition appears in an interface body or derived type 
> definition, those are not procedures. 
Sure, but the cobounds never needed to be determined. Perhaps there is a 
wording problem here but it is no different from having a dummy array 
argument x(N) where N is also a dummy argument.

> My followup question 3 relates to the BLOCK construct; viz, this is not 
> integrated into it.  The quoted text says that in
>    SUBROUTINE s(n) ! Suppose N is equal to 100 on entry.
>    ...
>    n = 10
>    BLOCK
>      REAL,SAVE :: cob[n:*]
>      cob[n] = 3 ! PROBLEM
> 
> that COB is declared with bounds equal to N on entry to the procedure 
> viz 100, so cob[n] being cob[10] will be an error.
Yes, I agree, it looks like this is in need of fixing.

Best,
Aleks