09-169r1 To: J3 From: Van Snyder/Bill Long Subject: Coarray wording redundancies or inconsistencies Date: 2009 May 4 References: 09-007r1 1. Discussion Some restrictions on coarrays are stated in more than one place. For reference, here are two constraints mentioned below: C444 A data component whose type has a coarray ultimate component shall be a nonpointer nonallocatable scalar and shall not be a coarray. C525 An entity whose type has a coarray ultimate component shall be a nonpointer nonallocatable scalar, shall not be a coarray, and shall not be a function result. Despite this, subgroup feels that retaining C444 is clearer. 2. Edits [37:12 2.4.7 Coarray, p4]---------------------------------------------- This edit is discussed in Reply 1 below. Editor: In the first sentence of p4 replace "another" with "any". In the second sentence of p4 replace "can be" with "can also be". [37:14 2.4.7p5]--------------------------------------------------------- C525 says a coarray is prohibited to have coarray components. Therefore "noncoarray" is not needed here. Editor: Delete "noncoarray". 3. Questions and remarks. Question 1: NOTE 2.14 [37:18+8 2.4.7p7] would benefit from a reference to the text that supports its assertion, if there is such text other than 2.4.7p4, which doesn't say what the note says (2.4.7p4 says "can" not "is"). Reply 1: Paragraph 4 of "2.4.7 Coarray" [37:12-13] says you can access a coarray locally without using cosubscripts. You can also access the coarray on the local image using cosubscripts that correspond to the executing image. Note 2.14 elaborates on what happens in these two cases. Perhaps changing "another" at [37:12] to "any", and then indicting that the syntax without cosubscripts is an alternative, would make this more clear. An edit for this is included above. Question 2: 12.5.2.8 [299:1] says that the actual argument corresponding to a coarray dummy argument has to be a coarray, but doesn't say anything about the dummy argument corresponding to an actual argument that is a coarray. 12.4.2.2 [281:20] says that a procedure has to have explicit interface if it has a coarray dummy argument, but says nothing about needing explicit interface if the actual argument is a coarray. If a coarray appears as an actual argument but the referenced procedure has implicit interface, is the coarray reference interpreted to be on the image that invokes the procedure? Probably so, since the corresponding dummy can't be a coarray. Does this need to be said somewhere explicitly, even if only in a note, or does NOTE 2.14 imply it (but without adequate normative support)? Reply 2: If a dummy argument that is not a coarray is associated with an actual argument that is a coarray, neither is allocatable. (If the corresponding arguments are allocatable, [298:12] restricts the dummy to be a coarray.) The actual argument is a local array, and the coarrays on other images corresponding to the actual argument are not accessible through the dummy argument. The rules restricting variable references or definitions in unordered segments [190:13-23] still apply. Defining the dummy argument causes the corresponding actual to be defined [458:7-10]. Causing the dummy to become undefined causes the corresponding actual to become undefined [459:32-40]. The same citations cause variables associated with the actual argument in the calling program unit to become defined or undefined. Thus, actions on the dummy argument might be limited, so to not cause prohibited references or definitions of the associated actual arguments or variables associated with them. It is OK for a procedure to not have an explicit interface if it has a coarray actual argument. This capability is needed to allow coarrays as arguments to dusty-deck library routines.