From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Wed Dec 25 18:27:27 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 5D610357087; Wed, 25 Dec 2013 18:27:27 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from exprod6og103.obsmtp.com (exprod6og103.obsmtp.com [64.18.1.185]) by www.open-std.org (Postfix) with ESMTP id 1E4303567F2 for ; Wed, 25 Dec 2013 18:27:24 +0100 (CET) Received: from CFWEX01.americas.cray.com ([136.162.34.11]) (using TLSv1) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP ID DSNKUrsVexr5fpc0ArCMrtTghMP/hi1nKkh4@postini.com; Wed, 25 Dec 2013 09:27:26 PST Received: from bill-longs-macbook-pro.local (192.168.233.184) by CFWEX01.americas.cray.com (172.30.88.25) with Microsoft SMTP Server id 14.2.347.0; Wed, 25 Dec 2013 11:25:14 -0600 Message-ID: <52BB1538.2070100@cray.com> Date: Wed, 25 Dec 2013 11:26:16 -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.5176) [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> <20131225041639.0E121358314@www.open-std.org> <20131225081949.46A743582FA@www.open-std.org> In-Reply-To: <20131225081949.46A743582FA@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/25/13 2:19 AM, Malcolm Cohen wrote: > I certainly have no objection to rethinking the way that we describe an > array-spec with a view to improving the exposition, quite the opposite. But > that would be for the next revision. And it is certainly unclear at this point > whether any real improvement could be made, or whether that would just be moving > the complications out of the BNF and into the prose (as mentioned above, that is > often a bad idea). OK, I now see you were focused on BNF ambiguity while I was focused on visual ambiguity. Hopefully I now get the concept behind the change: OLD (two syntax terms): is used to declare an assumed-size array. is used to declare an implied-shape array. NEW (Three syntax terms): is used to declare an assumed-size array of rank 2 or larger. is used to declare an implied-shape array of rank 2 or larger. is used for the rank 1 case of either assumed size or implied shape. It is unfortunate that is no longer the syntax for declaring any assumed-size array, but I guess that is a price we pay for choosing this answer to the interp. This is an improvement for BNF readers, but does not really do much for the programmer. I think it would be helpful (at least in F2015, if not in the interp) to add a Note at the end of 5.3.8.6, at [96:31+] something like: "NOTE 5.12a For arrays of rank 1, a declaration like DIMENSION :: X(*) or INTEGER :: X(*) declares either a dummy array or a named constant array, depending on whether X appears as a dummy argument in a prior FUNCTION, SUBROUTINE, or ENTRY statement in the program unit, or X appears a named constant in a subsequent PARAMETER statement in the program unit. The disambiguating FUNCTION, SUBROUTINE, ENTRY, or PARAMETER statement could be many lines separated from the declaration statements above. As a result, such declaration statements could be visually confusing. This confusion can be avoided if implied-shape arrays are always declared in a type declaration statement that contains the PARAMETER attribute, such as INTEGER,PARAMETER :: X(*) = [1,2,3] " Cheers, Bill -- 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