(j3.2006) Vote on revised draft DTS

[John Reid]

J3,

David reported transient problems with WG5 email and now I seem to have 
been affected. I sent this message on Saturday, but I don't think it 
ever got through, and I cannot send messages to WG5 just now. I am 
therefore sending this message to J3.

Malcolm's vote was late too. With my convener's hat on, I propose to 
accept both his vote and mine. Also, Reinhold wants to amend item (5C) 
(5) of his vote. I propose to accept this, too.

I sent out N1991-1 (first draft of the ballot result) on Sunday. I do 
not think this got through, either. I will send N1991-2 soon.

Best wishes,

John.

............................................................


John Reid wrote:
> WG5,
>
> I am about 11 hours late with my vote on the DTS. In the past, I have
> accepted votes that arrived before I had assembled the result. Is it OK
> for me to do this for myself? I plan to send a draft of my assembled
> document for you all to check. If you object to my adding my vote,
> please say so when you review this draft.
>
> My vote is NO for the following reasons:
>
> 1.
> Rather hurriedly in Delft, we added the option of a team variable
> appearing in an image selector, e.g., a[parent::i,j]. The intention  was
> to allow the cosubscripts of a coarray declared in an ancestor to be
> interpreted in exactly the same way in a change team construct as in the
> ancestor, for example, when performing halo exchanges.
>
> This does not work well if the coarray is a dummy argument because its
> name and the names of its ancestors are unknown. J3 therefore added the
> intrinsic GET_TEAM to place a copy of the value of the team
> variable of the ancestor at a level DISTANCE in a local team variable.
> It seems to me that a much better solution would be to specify the
> distance directly in the image selector, e.g., a[distance::i,j]. It is
> much simpler and there is far less scope for inconsistent setting of
> team variables. I would like GET_TEAM to be removed entirely.
>
> 2.
> We have added an optional DISTANCE argument to NUM_IMAGES. We
> need to do this also for LCOBOUND and UCOBOUND so that the coshape of
> an ancestor can be determined.
>
> 3.
> Add a new subroutine FAIL_IMAGE() whose effect is to cause the executing
> image to behave as failed. This is needed for the testing of a program
> that is intended to continue execution in the presence of failed images.
> An optional argument IMAGE might be added to give the effect of
> communication between the executing image and image IMAGE having failed
> - each would continue executing but see the other as failed.
>
> 4.
> I support the concept of RECODIMENSION that Reinhold Bader suggests in
> his ballot. I also support the view that Malcolm Cohen expressed in an
> email:
>
> "I would prefer different syntax to be used when one intends to
> re-codimension an array, perhaps
>    RECODIMENSION :: ...whatever
> and this would not be a general specification statement, but part of the
> CHANGE TEAM syntax which would then be
>     <change-team-stmt>
>     [ <recodimension-stmt> ]...
>     <block>
>    <end-change-team-stmt>
>
> And rather than "modifying the attribute of an existing object"
> (horrible), it would be declaring a "construct entity that is associated
> with the local entity of the same name".  We do already have construct
> entities that are associated with outer-scoped objects (via ASSOCIATE
> and SELECT TYPE) so this is not a new concept.
>
> In any case one must write quite a bit of new text to specify how this
> is going to work, but making it a construct entity is probably easier
> than making the CHANGE TEAM construct into a scoping unit thus wheeling
> out host association (already complicated) and then adding more
> complication to it.
>
>  > I suppose a logical question would be whether this should also be
>  > allowed in a BLOCK construct.  Perhaps that should be left as an
>  > integration issue.
>
> No, it cannot be left as an integration issue.  It should be either part
> of the CHANGE TEAM syntax (and described as a construct entity), or a
> normal specification-stmt in which case the CHANGE TEAM construct ought
> to be a scoping unit with a specification-part.  Or some slight tweak of
> those major options."
>
> 5. (An edit)
> [11:15-16]  Consider the sentence "The value of team-id species the team
> to which the executing image belongs."  This is nonsense: the current
> team is the team to which the executing image belongs. Replace it by
>   "The value of team-id species the new team to which the executing image
>   will belong."
>
>
>