To: J3 J3/13-335 From: Bill Long, John Reid Subject: Comments on Teams and TEAM_TYPE (5.1-5.2) Date: 2013 September 30 References: N1983, N1989, 13-333 Overview -------- This paper contains a portion of the responses to the comments in N1989, the results of the ballot on the TS 18508 draft N1983. The following identifiers are used to indicate the source of comments: Reinhold : Reinhold Bader Bill : Bill Long Tobias : Tobias Burnus Nick : Nick Maclaren Daniel : Daniel Chen Dan : Dan Nagel Malcolm : Malcolm Cohen John : John Reid Steve : Steve Lionel Van : Van Snyder along with {Ed} for the document editor. Discussion - Responses with edits --------------------------------- {Daniel 1.}: How is the team variable identifying the initial team initialized? Response: The TS does not specify a named variable for the initial team. The program can create one using FORM SUBTEAM at the beginning of the program, specifying the same subteam_id for each image. Note 5.1a contains an example of this. Alternatively, the new THIS_TEAM() intrinsic (See paper 13-333) could be used to specify a name directly. An edit is provided for the case that THIS_TEAM is not accepted. {Dan 1}: At [9:3] "synchronize with each other" is unclear whether "each other" refers to teams or images within a team. Response: The intent is images within a team. However, with the inclusion of cross-team references, the current sentence is problematic. An edit is provided. {Dan 2}: At [9:9] do not constrain the team variable to actually contain the team information. Response: The team variable could contain a pointer associated with a database entry elsewhere. Better wording is needed. An edit is provided. {Nick 1}: 5.1, p9:14-15. This states "Within the body of a CHANGE TEAM construct the current team is the subteam specified by the CHANGE TEAM statement.", which implies lexical scope only. This should say "Within the body of a CHANGE TEAM construct and in procedures called from it the current team ....". Response: This modification is not adequate if a CHANGE TEAM is executed (possibly within a called procedure) within an existing CHANGE TEAM construct. An edit is provided. {Bill I1}: At m201 it was asked why a TEAM_TYPE component of a structure is not allowed to have the POINTER attribute. Response: The intention was to prevent inappropriate definition or becoming undefined through assignment of the parent structure. Possibly not an issue because of the other constraints. An edit is provided to remove the restriction. {Reinhold, A.3): Allow POINTER attribute on team used in CHANGE TEAM, but not in FORM SUBTEAM. Response: Inclined to agree. An edit is provided to restrict FORM SUBTEAM. {Ed}: At [9:20-21] should the sentence "A team variable shall not be coarray or the subcomponent of a coarray." be a constraint? Response: Yes. An edit is provided. {Van 11}: [9:17] and [13:7] use inconsistent style. Response: Reword [9:17] to be like [13:7]. An edit is provided. {Van 1}: At [9:18] Insert "variable" after "scalar". Response: Agreed. An edit is provided. {Nick 2}: 5.2 and 5.3, p9:16-37. It is still not clear whether TEAM_TYPE has value or location semantics. C502 is not enough, because of the implicit copying implied by passing assumed-shape arrays to explicit-shape or assumed-size ones, and R502 says 'variable'. This must be clarified and is linked to some of the next points [A]. Response: It is intended that the implementation be free to use either value or location semantics. This requires restrictions to ensure that no alteration of the value of a team variable be allowed while it is a current team or an ancestor team. Since the only way to alter a team variable is with a FORM SUBTEAM statement, this needs a restriction. An edit is provided to restrict FORM SUBTEAM. Discussion - Responses only --------------------------- {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} 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." [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-21+] {Ed} Convert the second sentence of 5.2 TEAM_TYPE, para 2, "A team variable shall not be ... coarray" into a constraint C501- inserted before C501. [9:26] {Bill I1} Delete "shall not have the POINTER attribute and". [10:27-] {Daniel 1.} In Note 5.1 add a second paragraph (or a separate Note immediately following Note 5.1) "A named variable for the initial team is easy to construct. There is an example in NOTE 5.1a." [11:3+] Add a new constraint in 5.5 FORM SUBTEAM "C508a (R505) shall not have the POINTER attribute." [11:17]In the last para of 5.5 FORM SUBTEAM 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."