From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Sat Mar 9 05:31:23 2013 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id 41580356D85; Sat, 9 Mar 2013 05:31:23 +0100 (CET) Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 1965 seconds by postgrey-1.34 at www5.open-std.org; Sat, 09 Mar 2013 05:31:22 CET Received: from mail.jpl.nasa.gov (sentrion3.jpl.nasa.gov [128.149.139.109]) by www.open-std.org (Postfix) with ESMTP id 200E4356D4F for ; Sat, 9 Mar 2013 05:31:21 +0100 (CET) Received: from [137.79.7.57] (math.jpl.nasa.gov [137.79.7.57]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r293wVSl014895 (using TLSv1/SSLv3 with cipher DHE-RSA-AES256-SHA (256 bits) verified NO) for ; Fri, 8 Mar 2013 19:58:32 -0800 Subject: Alternative to CHANGE TEAM construct From: Van Snyder Reply-To: Van.Snyder@jpl.nasa.gov To: sc22wg5 Content-Type: text/plain; charset="ISO-8859-1" Organization: Yes Date: Fri, 08 Mar 2013 19:58:31 -0800 Message-ID: <1362801511.14487.845.camel@math.jpl.nasa.gov> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-24.el6) Content-Transfer-Encoding: 7bit X-Source-Sender: Van.Snyder@jpl.nasa.gov X-AUTH: Authorized Sender: owner-sc22wg5@open-std.org Precedence: bulk It's a bit late in the game to be pondering an alternative to CHANGE TEAM. Then again, clause 5 of 12-201 was empty, CHANGE TEAM was not mentioned in N1930, and then CHANGE TEAM sprang full-grown from the forehead of Zeus in 13-231, barely a month ago, and fewer than ten days before the start of meeting 200. There was very little discussion, i.e., none in e-mail before meeting 200, and only a few minutes on each of three days, only in J3, during meeting 200. People complain that the standard is getting too big, so if we can achieve the desired functionality with fewer or smaller mechanisms and less text, that would be desirable. To that end, I believe the functionality of the CHANGE TEAM construct would be better served by a WITH TEAM ( ) statement, similar to logical IF, FORALL, or WHERE statements, that admits a subset of action statements. Even simpler would be to allow only CALL statements, in which case it might be described as an optional WITH TEAM ( ) prefix of a CALL statement, the latter then allowing something like if ( do_this ) with team ( t ) call s ( ... ) which we might decide a WITH TEAM statement ought not to allow, especially if a WITH TEAM statement admits an . Compared to the CHANGE TEAM construct, the amount of new syntax, and associated constraints and description, would be reduced. With no construct, there could be no constraints on its relationship to CYCLE, EXIT, or RETURN statements, or on branching, and therefore no controversy where those constraints ought to be. A WITH TEAM statement, or a CALL statement having a WITH TEAM prefix, would be an image control statement. It would not be unreasonable to constrain against alternate returns. Alterations to the third paragraph of subclause 5.1 of N1967, and the three paragraphs and note after C503 in subclause 5.3, would not be of substantial scope or difficulty, and might result in slightly less text. This would simplify invoking a collective subroutine on a subteam of the current team, e.g. WITH TEAM ( T ) CALL CO_SUM ( A ). A TEAM argument for collective subroutines, not proposed in N1967, would never be needed. if WITH TEAM were a statement, SYNC TEAM might not be needed, using instead WITH TEAM ( T ) SYNC ALL. Unlike SYNC TEAM, however, this is an image control applying to the entire current team, not only team T. But then, it's not obvious when reading 13-251/N1967 what SYNC TEAM means. If SYNC TEAM means something like "If image M executes a SYNC TEAM statement, and the value of SUBTEAM_ID() for image M is S, then execution of the segment on image M of the segment following the SYNC TEAM statement is delayed until every image of the current team for which the value of SUBTEAM_ID() is S executes a SYNC TEAM statement specifying the same team...," the same logic could be applied to WITH TEAM, so that it would be an image control statement "for the specified team" (whatever that means) not for the entire current team. It's water over the dam now, but if we had provided the functionality of the CRITICAL construct by a MONITOR prefix for subroutines, the text, syntax, and constraints for that functionality would have been simpler. We could still someday provide monitor subroutines, and then maybe print the description of CRITICAL in obsolescent font, and then delete it.