From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Fri Feb 20 17:25:41 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 0992835730E; Fri, 20 Feb 2015 17:25:40 +0100 (CET) Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 693 seconds by postgrey-1.34 at www5.open-std.org; Fri, 20 Feb 2015 17:25:40 CET Received: from esa2.cray.iphmx.com (esa2.cray.iphmx.com [68.232.143.164]) by www.open-std.org (Postfix) with ESMTP id 164923568FD for ; Fri, 20 Feb 2015 17:25:37 +0100 (CET) X-IronPort-AV: E=Sophos;i="5.09,615,1418083200"; d="scan'208";a="465410" Received: from cray-smtp-2.cray.com (HELO CFWEX01.americas.cray.com) ([136.162.34.11]) by esa2.cray.iphmx.com with ESMTP/TLS/AES128-SHA; 20 Feb 2015 16:14:03 +0000 Received: from CFWEXHYBRID.americas.cray.com (172.30.88.178) by CFWEX01.americas.cray.com (172.30.88.25) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 20 Feb 2015 10:14:03 -0600 Received: from CFWEX01.americas.cray.com ([169.254.1.190]) by cfwexhybrid.americas.cray.com ([::1]) with mapi id 14.03.0224.002; Fri, 20 Feb 2015 10:14:02 -0600 From: Bill Long To: fortran standards email list for J3 CC: WG5 Subject: Re: (j3.2006) (SC22WG5.5448) [ukfortran] Response to TS ballot Thread-Topic: (j3.2006) (SC22WG5.5448) [ukfortran] Response to TS ballot Thread-Index: AQHQTPdIPt/54KxqE06RCGaUFSbzdJz6GyKA Date: Fri, 20 Feb 2015 16:14:01 +0000 Message-ID: <8FF3F37C-B193-4E1F-BF9B-45BE6F7F79AC@cray.com> References: <20150219231019.EF7E83570D2@www.open-std.org> <20150220023038.D13963570D2@www.open-std.org> <20150220102327.2E0A1358354@www.open-std.org> In-Reply-To: <20150220102327.2E0A1358354@www.open-std.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.233.140] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-sc22wg5@open-std.org Precedence: bulk On Feb 20, 2015, at 4:22 AM, John Reid wrote: >=20 >=20 > Malcolm Cohen wrote: >> Two spectacular misses. >>=20 >> (1) >> I wrote: >> I note that in the case of executing code >> outside (but called from) a CHANGE TEAM construct, "innermost" has no me= aning. >>=20 >> To which you propose to make the edit: >> [14:29] Replace "construct" by "innermost executing CHANGE TEAM >> construct". >>=20 >> Innermost has a good meaning if you accepted my other recommendation, th= at this >> effect be limited to code actually within a CHANGE TEAM construct, but y= ou >> rejected that. >>=20 >> So I have to repeat again, "INNERMOST" HAS NO MEANING in the case of exe= cuting >> code outside (but called from) a CHANGE TEAM construct. Innermost is a = spacial >> term referring to the placement of statements and constructs *Lexically = Within* >> other constructs. It is not a temporal term referring to the order of >> execution! >>=20 >> Perhaps you mean something like "active CHANGE TEAM construct that most = recently >> begun execution"? In which case, that is something like what you need t= o say. >=20 > Agreed. That is the intent. Even though having multiple CHANGE TEAM constructs act= ive at the same time will probably be rare, we need to account for the poss= ibility.=20 >=20 >> There could well be MANY "innermost" CHANGE TEAM constructs being execut= ed... >>=20 >> I further note that you went without my suggestion of "whose END TEAM st= atement >> has a STAT=3D specifier". It seems pointless to transfer control to an = END TEAM >> statement without a STAT=3D specifier since that will immediately cause = error >> termination. If that is your intent, would it not be better to have err= or >> termination immediately (at the erring code) rather than in the END TEAM >> statement? (The user will thank you for not throwing away the info abou= t where >> the problem occurred!) If that is not your intent, well=85 A reasonable option is to say that the image error stops immediately on a s= tall if there is no STAT=3D in the END TEAM. Besides better traceback info= rmation, this allows the implementation to skip facilities that would be in= volved in unwinding the program state if it can see there is no STAT=3D in = the END TEAM. It basically gives the user another way of saying =93The alg= orithm is not recoverable, so chuck everything if an image fails." >=20 > In this case, I think we need to say that the image stays stalled for eve= r. >=20 >>=20 >> (2) >> I wrote: >> - The syntax is "FAIL IMAGE ". I see no purpose in using the >> BNF rule here. >>=20 >> You reply: >> The BNF rule defines what the user can write. >>=20 >> ...which is PRECISELY my complaint. WHY is the user being limited in th= is way? >> Why on earth should this be required to be a constant expression? The Why do we have that requirement on STOP statements? For a character , all of the cases are basically the same as write (error_unit,*) flush (error_unit) stop/error stop/fail image which, of course, the user could code directly. One advantage of requiring= a constant is that it prevents the from being coindexed. You = really don=92t want an image to stall while it is trying to fail (or stop o= r error stop). Another is the practical one of being able to scan the prog= ram source for the text that was output so you can easily find where the im= age stopped (assuming the programmer didn=92t use the same message on multi= ple statements). An advantage of using a directly on the STOP= /ERROR STOP/FAIL IMAGE statement instead of the sequence of three statement= s is that the three statements could be split across subprograms, again los= ing the benefit of locating the stopping point in the program source.=20 I do agree that we don=92t want the programmer to select a numerical exit s= tatus for the failed image. The implementation needs control so it can sen= d the right signal to indicate that this image is dead, but leave the rest = of the program running. But the implementation has the flexibility to not = send the user-supplied value as the exit status in the FAIL IMAGE case.=20 >> syntax is irregular and unnecessary. Just make it an expres= sion of One could argue that i would be irregular to treat FAIL IMAGE as all that d= ifferent from STOP and ERROR STOP. They all have the effect of causing the= image to not execute any more statements. At least that was the rationale= for including the in the first place.=20 Cheers, Bill >> type integer or character. Or even just type character (there is no "pr= ocess >> exit status" to be set here). >=20 > Agreed. >=20 > Cheers, >=20 > John. >=20 > _______________________________________________ > J3 mailing list > J3@mailman.j3-fortran.org > http://mailman.j3-fortran.org/mailman/listinfo/j3 Bill Long = longb@cray.com Fortran Technical Suport & voice: 651-60= 5-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101