From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Tue Apr 7 08:47:22 2015 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 1F65F358813; Tue, 7 Apr 2015 08:47:22 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from nag-j.co.jp (nag-j.co.jp [111.68.142.10]) by www.open-std.org (Postfix) with ESMTP id A5455358538 for ; Tue, 7 Apr 2015 08:47:16 +0200 (CEST) Received: from Maru6 (218-42-159-105.cust.bit-drive.ne.jp [218.42.159.105]) (authenticated bits=0) by nag-j.co.jp (8.14.5/8.14.5) with ESMTP id t376lBIw029408 for ; Tue, 7 Apr 2015 15:47:13 +0900 (JST) (envelope-from malcolm@nag-j.co.jp) Message-ID: <43D533144AA34A1E85079217C103AEF3@Maru6> From: "Malcolm Cohen" To: "WG5" Subject: WG5 straw ballot on N2048 Date: Tue, 7 Apr 2015 15:47:12 +0900 Organization: =?iso-2022-jp?B?GyRCRnxLXBsoQk5BRw==?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_019D_01D0714A.1CFD5F30" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_019D_01D0714A.1CFD5F30 Content-Type: text/plain; format=flowed; charset="iso-2022-jp"; reply-type=original Content-Transfer-Encoding: 7bit >"Is N2048 ready for forwarding to SC22 as the PDTS?" No. See attached. Comment: N2048 is technically much better than before, but some of the expository flaws are still serious. Addressing my identified major issues will change my vote to Abstain (unfortunately I've run out of time to review the rest of the contents sufficiently to be able to be more positive). Cheers, -- ................................Malcolm Cohen, Nihon NAG, Tokyo. ------=_NextPart_000_019D_01D0714A.1CFD5F30 Content-Type: text/plain; format=flowed; name="N2048-vote.txt"; reply-type=original Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="N2048-vote.txt" Vote: NO. All major technical issues need to be addressed to change my vote from No. Terminology: ------------ (0a) MAJOR ISSUE: The term "current team" is a poor name. Apart from the fact that the word "current" is frowned upon by ISO, there is no unique "current team", each image has its own "current team". I think that "active team" would be better - it is more understandable that this is per-image. That this is a major issue is demonstrated by the need to talk about the "current current team" vs the "current team at the time of execution of the blah statement", etc. (Yes, the TS does not generally do this, but that's because it is not being rigorous enough to avoid ambiguity.) In the further edits below I am sticking with "current team", this is so as not to conflate other issues with the terminological ones. (0b) The term "team identifier" is a poor choice, as there is no expectation of uniqueness and the team thus identified varies dynamically. A better term would be "team number"; that is, it is more like an input/output unit number than it is like a unique identifier. (0c) The definition of "established coarray" is confusing, precisely what this term means is also confusing -- no fix proposed. (0d) In several contexts the concept of "sub-team" would be useful, in particular it might make some of the wording more accurate and/or less convoluted in places. I think we can just use that word without definition, or we could say something like "The sub-teams of a team are those teams which have that team as a parent team." (0e) There is a singular occurrence of "associating coarray", and two mentions of coarrays that are or are not an "associating entity" that does not say that these are "associating coarrays". I note that an associate-name can be a coarray, in which case its variable is an associating entity. But that is probably not intended to be an "associating coarray". So some better terminology or use of existing terminology seems to be required. Major Technical Issues: ----------------------- (1) The definition of "current team" is completely defective; "innermost" is meaningless in this context. Also, it needs to be qualified with "of an image", since each image has its own current team [5:23-24] 3.5.1 current team, replace definition with qualification and text as follows "\termqual{of an image} team specified by the most recently executed CHANGE TEAM statement of an active CHANGE TEAM construct, or initial team if no CHANGE TEAM construct is active". (2) The term "team identifier" is ambiguously and confusingly described: definition says it is an "integer value identifying a team" according to which, all members of a team must have the same team id, and implicitly if two images have the same team id they belong to the same team; the second of these is clearly false in general. Do we need the definition? Maybe (the term is used in several places); in which case it would seem that a simpler operational definition would work. "value specified by this image as the in the FORM TEAM statement for the current team" according to the TEAM_ID intrinsic: "If the specified team is the initial team, the result is -1; otherwise, the result value is the team identifier of the invoking image in the specified team." which sounds like a team can have images with differing team identifiers, contradicting the definition. There is no statement anywhere which actually says how the team identifier is determined; one might think that FORM TEAM would do that, but it does not. As mentioned above I would prefer a term like "team number", but in any case it needs more careful and not internally contradictory description. [5:33] 3.5.4 team identifier, replace definition "integer value identifying a sub-team of a parent team" {See comment above on using "sub-team".} (3) 5.1p2 regurgitates the definition of "current team", which if we follow the ISO guidelines makes it an empty tautology viz "The team that is specified in the CHANGE TEAM blah blah, is the team that is specified in the CHANGE TEAM blah blah." This should be written as explanation, not as empty consequences. (I note that an alternative approach would be to have the definition of "current team" be the explanatory one, and to specify here how it is changed and what the consequences are.) NOTE: This absolutely needs to be changed because the current text is nonsensical vis-a-vis "innermost". [9:10-11] 5.1 Introduction, p2, replace with "During execution, each image has a current team, which is only changed by execution of CHANGE TEAM and END TEAM statements. Executing a CHANGE TEAM statement changes the current team to the team specified by the , and execution of the corresponding END TEAM statement restores the current team back to its state immediately prior to execution of the CHANGE TEAM statement." {More wordsmithing probably useful, but I think this is better than simply repeating the definition tautologically.} (4) More FORM TEAM defects. "The FORM TEAM statement defines for a new team. The value of specifies the new team to which the executing image will belong. The value of team-id shall be positive and is the same for all images that are members of the same team." This is at best ambiguous. When FORM TEAM is executed by all active images of the current team, they are all on "the same team" but they are not necessarily giving the same value. Nowhere does it say that the specifies the "team identifier" (which is not unique, but that is a separate issue). Nowhere does it say that is assigns the a value that specifies the team that the image will belong to. [12:8-10] 5.5 FORM TEAM statement, p1, replace with something like: "The FORM TEAM statement creates one or more teams from the active images of the current team. The value of shall be positive. The team identifier of each new team is its unique value. Successful execution of FORM TEAM assigns the on each participating image a value that specifies the new team that the image will belong to." {This could use further wordsmithing, but is a start.} Minor Technical Issues: ----------------------- Problem: "current team" and "initial team" definitions are circular, in fact "initial team" is completely content-free. I am not convinced that we need a special term for the garden variety English "initial team" at all. Fix: [5:27] 3.5.2 initial team, delete or replace with the following: "team, consisting of all images, that began execution of the program". Problem: "parent team" definition is wrong (does not only apply to current team) and as the term is hardly used anyway, is unnecessary. Fix: [5:27-29] 3.5.3 parent team, delete. Problem: "failed image" definition is a regurgitation of the waffle from its subclause, is not properly grammatical, and is at best ambiguous and at worst wrong, since references or definitions of a variable do not fail - in fact they work as specified by the TS, even though the user might think this is somewhat mysterious behaviour. This needs to be replaced by a simpler definition. Fix: [5:36-38] 3.6 failed image, replace definition with "image that has ceased participating in program execution but has not initiated termination" {Just say what we mean without going into the details of what the consequences are.} Editorial fixes: ---------------- Many of the terms and definitions have defective definitions; these should all be noun clauses with no article. Also plural should be avoided. [5:6] 3.1 active image "An image" -> "image". [5:9-10] 3.2 asynchronous progress, replace with "ability of an image to reference or define a coarray on another image without waiting for that image to execute any particular statement or class of statement" {"require" is wrong, since that would entail a requirement being imposed by the standard, which is not what is meant here; and it should all be singular} [5:11-14] 3.3 collective subroutine, delete. {This definition is useless and uninteresting.} [6:1] 3.7 stopped image, "an image" -> "image". [9:2] 5.1 "Introduction" -> "Team concepts". {This is introductory matter explaining team concepts, so...} ------=_NextPart_000_019D_01D0714A.1CFD5F30--