(j3.2006) Fundamental comment on 17-201r1

[Malcolm Cohen]

The protestations that ?HPC at least? imagined that a team value could only be used at all on the image that generated it would be a lot more convincing if the TS had not gone out of its way to make team values copyable from one image to another, easily and without changing the value i.e. still identifying the team.  And CHANGE TEAM and FORM TEAM in the TS both apparently permit the ?team variable? to be coindexed ? so you can generate them onto another image and use them from another image directly.

That is, as far as I can tell, the evidence of all the technical requirements on team values points to them being usable on any member of the team.

That brings us to the ?guarantee of good behaviour? in the Introduction:
<<<
It is the intention of ISO/IEC JTC 1/SC22 that the semantics and syntax specified by this Technical Specification
be included in the next revision of ISO/IEC 1539-1 without change unless experience in the implementation
and use of this feature identifies errors that need to be corrected, or changes are needed to achieve proper
integration, in which case every reasonable effort will be made to minimize the impact of such changes on existing
implementations.
>>>

In my opinion the disadvantages of allowing team values to be used on other members of the team do not reach the bar of an ?error that needs to be corrected? (it?s certainly not a change needed to achieve proper integration to the rest of the language).  It?s a bit more work for the implementor who?s not already started on this, and taking advantage of it (viz actually using a team value on another image) is likely to be a bit less performant than using a team value that was generated on an image, but these look like molehills not mountains.

That said, if it is the decision of the rest of WG5 that the model described needs to be changed in the way envisaged by 17-201r1, well, it?s WG5?s decision to make.  (I will almost certainly continue to think that it?s a bad decision though!)

If that happens, in my opinion we should be using the existing infrastructure and models in the standard to describe the effects.  For team variables/values, the way we do this for everything else that cannot be copied from a remote image is to say that the variable becomes undefined.

There is an utterly trivial way to do this: change the TEAM_TYPE definition to say that it includes a pointer component.  That will automatically trigger ?becomes undefined? when a TEAM_TYPE value is copied from one image to another.  (And if it contains a pointer component I suspect it need not contain an allocatable component as well, but that?s a technical detail for another discussion.)

Secondly, the team-value in CHANGE TEAM and the team-variable in FORM TEAM should be constrained not to be coindexed.

Thirdly, TEAM_TYPE should be prohibited from being a coarray.  I?m pleased to see that this has already been thought of, but it needs to be in a single paper together with the other changes to make TEAM_TYPE values usable only on the generating image.  That?s so we can see the final effect all at once in one place, and it also provides insurance in case WG5 does not go along with the change (a single paper is a lot easier to back out of the draft 007 than a hodgepodge of papers).

Yes these things are all TECHNICAL CHANGES from the TS, but the ?new model? described in 201 is itself a fundamental change from the words of the TS.  If we?re going to make a fundamental change, IMO we should be making the result as proper and robust as we can, which means all three items I?ve mentioned above.  Oh, and drop the idea of ?a TEAM_TYPE refers to an image?.  The current terminology is an improvement on that.

P.S. While I?m thinking of it, we seem to be silent on whether variables of TEAM_TYPE have any final subroutine, and if so, whether that final subroutine is pure.  But that is a horse of a different colour...  perhaps we should in any case close its stable door before it bolts.

Cheers,
-- 
...........................Malcolm.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.j3-fortran.org/pipermail/j3/attachments/20171018/16f4c3d1/attachment-0001.html>