From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Wed Dec 25 05:16:38 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 E21863582FA; Wed, 25 Dec 2013 05:16:38 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from exprod6og125.obsmtp.com (exprod6og125.obsmtp.com [64.18.1.218]) by www.open-std.org (Postfix) with ESMTP id 089543582F4 for ; Wed, 25 Dec 2013 05:16:36 +0100 (CET) Received: from CFWEX01.americas.cray.com ([136.162.34.11]) (using TLSv1) by exprod6ob125.postini.com ([64.18.5.12]) with SMTP ID DSNKUrpcI3QzxiAyEgkxoRFbMLI36gtQPQy8@postini.com; Tue, 24 Dec 2013 20:16:38 PST Received: from bill-longs-macbook-pro.local (192.168.233.185) by CFWEX01.americas.cray.com (172.30.88.25) with Microsoft SMTP Server id 14.2.347.0; Tue, 24 Dec 2013 22:16:34 -0600 Message-ID: <52BA5C5F.6050809@cray.com> Date: Tue, 24 Dec 2013 22:17:35 -0600 From: Bill Long Reply-To: Organization: Cray Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: sc22wg5 Subject: Re: (j3.2006) (SC22WG5.5174) [ukfortran] Draft result of ballot on Corrigendum 3 References: <20131224160359.87D023582DB@www.open-std.org> <20131224204504.9F3FD358314@www.open-std.org> <20131225003521.1B949357087@www.open-std.org> In-Reply-To: <20131225003521.1B949357087@www.open-std.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-sc22wg5@open-std.org Precedence: bulk On 12/24/13 6:35 PM, Malcolm Cohen wrote: > Bill Long writes: >> Are the replacement edits really correct? > > Yes. > >> On 12/24/13 10:03 AM, John Reid wrote: >>> [95:33-] Insert new BNF term >>> "R520a <> [ : ] *" >>> >> >> OK, a new, reusable name for [:]* . > > Yes. > >>> [95:33] R521 , after "<>" >>> Replace entire RHS >>> "[ , ]... [ : ] *" >>> with >>> ", " >> >> So now there is a mandatory comma as part of this syntax? > > I should hope so!!!!! Having no comma between the preceding > explicit-shape-spec-list and the assumed-implied-spec would be a serious error, > e.g. > > REAL X(1:100 30:*) > > I think we can all agree there needs to be a comma between the > explicit-shape-spec-list "1:100" and the assumed-implied-spec "30:*". > >> It would seem this should be >> >> "[,] " > > No, the case when the explicit-shape-spec-list is missing is the ambiguous case. > Which is why we have the edit > >>> [95:32] 5.3.8.5p1 >>> Replace sentence >>> "An assumed-size array is declared with an ." >>> with >>> "A dummy argument is declared to be an assumed-size array by an >>> or an ." >>> {Now two ways of declaring assumed size.} > > ... >>> [96:26] R522, >>> Replace right-hand-side (after "<>") >>> "[ : ] *" >>> with >>> ", ". >> >> Similarly here, should this not be >> >> " [, ]" > > No. > >> or better, just >> >> "" > > No. > >> since the <-list> syntax requires at least one instance of the thing being >> qualified. [22:16]. > > Those just reintroduce the ambiguity the interp is complaining about in the > first place... the complaint wasn't "we don't have a catchy name for [ > : ] *", it was "the syntax is ambiguous". The catchy name is only > introduced because it simplifies the otherwise-confusing BNF and prose > descriptions. I hardly see this as "simple". Not to mention the confusing wording for error messages that use syntax terms. How is Q2 of the interp any different from subroutine test2(a) character(*) :: a,c parameter (c = "string") a = c end We don't seem to have an issue with a * for the length type parameter meaning two different things in the same statement. It is disambiguated by whether the entity is a dummy argument. We manage to say that in normative text, and there is no problem with the code above. The same should be true for the dimension case which looks the same. The real contradiction in the original interp was the requirement that the "shape" had to be previously specified, instead of only the rank. All of the new syntax seems extraneous and unnecessarily confusing. Cheers, Bill > > Cheers, > -- Bill Long longb@cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101