To: J3 J3/13-335r3 From: Bill Long, John Reid Subject: Comments on Teams and TEAM_TYPE (5.1-5.2) Date: 2013 October 16 References: N1983, N1989, 13-333r1 Discussion ---------- {Dan 1}: The phrase "synchronized with each other at [9:3] refers to images within a team. However, with the inclusion of cross-team references, the current sentence is problematic. An edit is provided. {Dan 2}: The text at [9:9] is not intended to constrain the team variable to actually contain the team information. The team variable could contain a pointer associated with a database entry elsewhere. A clarifying edit is provided. {Nick 1}: 5.1, p9:14-15. The team that applies between a CHANGE TEAM and the corresponding END TEAM is the one specified in the CHANGE TEAM statement, except in contained CHANGE TEAM blocks. The current text implies a lexical scope, not allowing for called procedures within the construct or contained CHANGE TEAM constructs. An edit is supplied. {Bill I1}: A TEAM_TYPE component of a structure should be allowed to have the POINTER attribute. An edit is provided to remove the existing restriction. {Reinhold, A.3): The POINTER attribute should be allowed for a team variable. The Edit for {Bill I1} covers this case. {Ed}: At [9:20-21] the sentence "A team variable shall not be coarray or the subcomponent of a coarray." should be a constraint. An edit is supplied to change this. {Van 11}: [9:17] and [13:7] use inconsistent style. The text at [9:17] is changed to be like [13:7]. An edit is provided. {Van 1}: At [9:18] "variable" should be inserted after "scalar". An edit is provided. {Van m5}: A team variable should have default initialization with the initial value that is not valid. {Nick 7} The current text allows for memory leaks because team variables can be created (allocated) but not deallocated. Edits are provided to allow deallocation. {Nick 2}: 5.2 and 5.3, p9:16-37. It is intended that the implementation be free to use either value or location semantics for a value of type TEAM_TYPE. This requires restrictions to ensure that no alteration of the value of a team variable be allowed while it is the current team or an ancestor team. Since the only way to alter a team variable is with a FORM TEAM statement or a call to THIS_TEAM, this needs a restriction. An edit is provided to restrict FORM TEAM. {Van m3}: A team variable should not be an actual argument corresponding to an INTENT(OUT) dummy in a call with an implicit interface. The solution is to require an explicit interface in this case. Discussion - Responses without edits ------------------------------------ {Bill I2}: At [9:22-29, 13:15-22] We now have very similar sets of constraints for variables of type LOCK_TYPE, TEAM_TYPE, and EVENT_TYPE. The basic reason is the same in all cases - the desire to restrict definition of such variables to a limited set of statements. Perhaps constraints for a new concept, such as "restricted type" or "restricted-use type" could be written once and then referenced for the three cases. Response: For the TS, make the change in {Van 11}.. Otherwise, there are enough differences to make this not a worthwhile endeavor. A team variable is required not to be a coarray, whereas an event or lock variable is required to be a coarray. The variable definition contexts in which the variables may appear differ (lock/unlock, form subteam, event post/wait). A team variable has an additional pointer restriction. Edits to N1983 -------------- [9:3] {Dan 1} Replace the first sentence of 5.1 "A team ... each other." by "A team of images is a set of images that can readily execute independently of other images." [9:8-9] {Dan 2} Replace the sentence "Information ... variable." by "Information about the team to which the current image belongs can be determined by the processor from the collective value of the team variables on the images of the team." [9:14-15] {Nick 1} Replace the para "Within the body ... statement." by "The current team is the team specified in the CHANGE TEAM statement of the innermost executing CHANGE TEAM construct, or the initial team if no CHANGE TEAM construct is active." [9:17] {Van 11, m5} Replace the first two sentences of 5.2 TEAM_TYPE, para 1 "The derived type...are private." by "TEAM_TYPE is a derived type with private components. It is an extensible type with no type parameters. Each component is fully default initialized." [9:18] {Van 1} In the third sentence of 5.2 TEAM_TYPE, para 1, replace "scalar of this type" with "scalar variable of this type". [9:20] {Van m5} After the first sentence of 5.2 TEAM_TYPE, para 2, add a new sentence: "The default initial value of a team variable shall not represent any valid team." [9:20-21+] {Ed} Convert the last sentence of 5.2 TEAM_TYPE, para 2, "A team variable shall not be ... coarray" into a constraint C501- inserted before C501. [9:24] {Nick 7} Before "or as a" add "as an in a DEALLOCATE statement," [9:26] {Bill I1} Delete "shall not have the POINTER attribute and". [9:29+] {Nick 7} Add paragraph: "The team variable for the current team or an ancestor team shall not be deallocated." [11:17] {Nick 2} In the last para of 5.5 FORM TEAM change the sentence "The team variable ... current team" to "The team variable shall neither be the team variable for the current team or an ancestor team nor be associated with the team variable for the current team or an ancestor team." [29:3+] {Van m3} Add a new subclause to clause 8: "8.6a Edits to clause 12 {In 12.4.2.2 Explicit interface, in list item (2)(d) remove "or", in list item (2)(e) append "or" and add a new item (2)(f) as follows} (f) is of type TEAM_TYPE, or of a type with a subcomponent of type TEAM_TYPE. "