From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Tue Mar 29 01:14:02 2016 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 1FA7135885D; Tue, 29 Mar 2016 01:14:02 +0200 (CEST) Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 1852 seconds by postgrey-1.34 at www5.open-std.org; Tue, 29 Mar 2016 01:14:00 CEST Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by www.open-std.org (Postfix) with ESMTP id CAEA63568A8 for ; Tue, 29 Mar 2016 01:13:57 +0200 (CEST) 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 u2SMh0bd022574 (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128 bits) verified NO); Mon, 28 Mar 2016 15:43:01 -0700 Subject: Re: (j3.2006) (SC22WG5.5689) [ukfortran] AW: RE: F08/C201 From: Van Snyder Reply-To: Van.Snyder@jpl.nasa.gov To: fortran standards email list for J3 Cc: WG5 In-Reply-To: <20160317055338.21A253584A2@www.open-std.org> References: <20160314163910.3E1A035730E@www.open-std.org> <20160315002027.D448E3582CC@www.open-std.org> <20160315200858.1DA5E3587BB@www.open-std.org> <20160316075309.C2B803571CA@www.open-std.org> <20160316131948.4819C357127@www.open-std.org> <20160317055338.21A253584A2@www.open-std.org> Content-Type: text/plain; charset="ISO-8859-1" Organization: Yes Date: Mon, 28 Mar 2016 15:43:00 -0700 Message-ID: <1459204980.11795.621.camel@math.jpl.nasa.gov> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-34.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 was proposed to delete the four syntax terms mentioned in C201 from , and then delete C201, in 06-188r1. The only place this has effect in 16-007, as far as I can tell, is in 1.3.134.2, where those four statements would need to be mentioned explicitly. Subgroup A chose to take no action, without explanation. On Thu, 2016-03-17 at 14:54 +0900, Cohen Malcolm wrote: > The way that the end statements are counted in and C201 > excludes them from appearing as executable constructs is at best confusing, > whether it is technically wrong or not. > > FWIW, on close examination I do think it probably is technically wrong, as > the end statement (does not need "subroutine" - that is an optional keyword > in this context) in the interface body in the BLOCK construct is indeed > reached via executable-construct. > > Not that a compiler is likely to take that interpretation. > > This could be patched by modifying C201, but since this looks like a very > confusing way of describing the grammer anyway, I would be more in favour of > getting the end statements out of action-stmt and inserting them as > necessary elsewhere, unless that turns out to be more difficult than it > looks. We would certainly want to be very careful how we change this > otherwise the chance of incidental BNF breakage would be quite high. > > Cheers, > > -----Original Message----- > From: Robert Corbett > Sent: Wednesday, March 16, 2016 9:04 PM > To: fortran standards email list for J3 > Cc: Forcheck ; Bader, Reinhold ; 'WG5' > Subject: [ukfortran] (SC22WG5.5686) (j3.2006) AW: RE: F08/C201 > > On 03/16/16 00:46, Bader, Reinhold wrote: > > Hi Erik, > > > > my impression is that C201 only closes a hole that would otherwise permit > > improper nesting of statements with respect to executable constructs, > > e.g., > > > > block > > ... > > end subroutine > > end block > > > > Cheers > > Reinhold > > > > You and Erik raise a fair point. Constraint C201 has the same effect on the > syntax as would be achieved by deleting the alternatives > /end-function-stmt/, > /end-mp-subprogram-stmt/, /end-program-stmt/, and /end-subroutine-stmt/ from > rule R214 (rule R215 of 16-007), which is the syntax definition of an > /action-stmt/. I suspect that the intended purpose of including those > alternatives is to indicate that those forms of END statements are > executable > constructs. That does not work, because none of the cases where one of > those > forms of END statements is produced by the grammar are derived (indirectly) > from > the syntax term /executable-construct/ because of the constraint. > > Robert Corbett > > _______________________________________________ > ukfortran mailing list > http://lists.accu.org/mailman/listinfo/ukfortran >