From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Fri Sep 30 15:56:56 2011 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 7F1363568E5; Fri, 30 Sep 2011 15:56:56 +0200 (CEST) Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 312 seconds by postgrey-1.34 at www5.open-std.org; Fri, 30 Sep 2011 15:56:56 CEST Received: from mx02.qsc.de (mx02.qsc.de [213.148.130.14]) by www.open-std.org (Postfix) with ESMTP id 4C7C33568C5 for ; Fri, 30 Sep 2011 15:56:56 +0200 (CEST) Received: from [192.168.178.22] (port-92-204-118-176.dynamic.qsc.de [92.204.118.176]) by mx02.qsc.de (Postfix) with ESMTP id 071831E650; Fri, 30 Sep 2011 15:51:39 +0200 (CEST) Message-ID: <4E85C96B.2090306@net-b.de> Date: Fri, 30 Sep 2011 15:51:39 +0200 From: Tobias Burnus User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110922 Thunderbird/7.0 MIME-Version: 1.0 To: longb@cray.com, fortran standards email list for J3 CC: David Muxworthy , "sc22wg5@open-std.org" Subject: Re: (j3.2006) (SC22WG5.4544) Comments on the technical content of the coarray TS References: <20110928104528.40F3C3568E7@www.open-std.org> <20110930113900.C09F63568CA@www.open-std.org> <4E85BB40.3000907@cray.com> In-Reply-To: <4E85BB40.3000907@cray.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-sc22wg5@open-std.org Precedence: bulk On 09/30/2011 02:51 PM, Bill Long wrote: > I think an important question that needs to be decided is whether the > goal of the TS is to include only those features that are already in > demand (from users) or that users through (having failed to carefully > read f2008) were already standardized, leaving more general expansion > to the next revision, or whether the TS should be a comprehensive > extension of coarrays that would unlikely be modified in the next > standard. I would argue that the current TS draft is somewhere > between these tow options. Going with the minimal TS would allow for > quicker completion and sooner start on f201x. The larger version > would possibly result in better long-term integration of the feature. > At this point, my personal preference is for the minimal approach. I cannot say anything about the meeting agreements, but as a Fortran user and Fortran-compiler developer, I am also in favour for a smaller TS. Given that the number of compilers well supporting coarrays (as defined in Fortran 2008) is very low, the practical experience with the newer features is still rather low. Thus, adding the most important missing features as TS allows to draw on user experience for additional features during the F201{3,8} development. For me, the collective/broadcast feature is the most important omission; having some subdivision (teams) or collective I/O seems to be of lesser importance (for my projects at least). Tobias