From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Thu Dec 11 20:49:04 2014 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 890073585D2; Thu, 11 Dec 2014 20:49:04 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.105]) by www.open-std.org (Postfix) with ESMTP id 00D22356F80 for ; Thu, 11 Dec 2014 20:48:59 +0100 (CET) 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 sBBJmuuR004319 (using TLSv1/SSLv3 with cipher DHE-RSA-AES128-SHA (128 bits) verified NO) for ; Thu, 11 Dec 2014 11:48:57 -0800 Subject: Re: (j3.2006) (SC22WG5.5385) Straw vote on draft DTS From: Van Snyder Reply-To: Van.Snyder@jpl.nasa.gov To: WG5 List In-Reply-To: <0EF5DA3D-6652-44A7-8859-70A05437D64B@rouson.net> References: <20141108182113.6EC5E3581CE@www.open-std.org> <20141207195158.20EE0358488@www.open-std.org> <0EF5DA3D-6652-44A7-8859-70A05437D64B@rouson.net> Content-Type: text/plain; charset="UTF-8" Organization: Yes Date: Thu, 11 Dec 2014 11:48:56 -0800 Message-ID: <1418327336.27194.122.camel@math.jpl.nasa.gov> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-34.el6) Content-Transfer-Encoding: 8bit X-Source-Sender: Van.Snyder@jpl.nasa.gov X-AUTH: Authorized Sender: owner-sc22wg5@open-std.org Precedence: bulk On Thu, 2014-12-11 at 11:26 -0800, Damian Rouson wrote: > I’ve been for some time touting the failed-image feature set as an > example of Fortran leading the way in an area that everyone recognizes > as important at the exascale. Letting this feature set slip beyond > Fortran 2015 would likely push Fortran to the back of the pack just as > more and more users are getting access to coarrays. We need for their > early experiences with corrays to be positive and for the path forward > to appear promising. I agree with Damian that this is an area with problems that need to be addressed. I am concerned that all of the details of all of the problems inherent in the solution proposed in the TS have not been discovered and worked out. If the provision in the Introduction that "the semantics and syntax specified by this Technical Specification be included in the next revision of ISO/IEC 1539-1 without change" were removed, or the caveat "changes are needed to achieve proper integration" were weakened to allow whatever substantive technical changes are necessary to address unforeseen problems, I would vote to approve the TS. Otherwise, I fear it has the potential to require an avalanch of interps.