From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Fri Apr 18 21:39:43 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 3965F358676; Fri, 18 Apr 2014 21:39:43 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from ppsw-40.csi.cam.ac.uk (ppsw-40.csi.cam.ac.uk [131.111.8.140]) by www.open-std.org (Postfix) with ESMTP id E2B5A358385 for ; Fri, 18 Apr 2014 21:39:40 +0200 (CEST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:54878) by ppsw-40.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:nmm1) id 1WbEdO-0005in-kg (Exim 4.82_3-c0e5623) (return-path ); Fri, 18 Apr 2014 20:39:38 +0100 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1WbEdO-00026u-Ch (Exim 4.72) (return-path ); Fri, 18 Apr 2014 20:39:38 +0100 Received: from [46.208.46.93] by old-webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.5); 18 Apr 2014 20:39:38 +0100 Date: 18 Apr 2014 20:39:38 +0100 From: "N.M. Maclaren" To: Damian Rouson Cc: fortran standards email list for J3 , WG5 Subject: Re: [ukfortran] (SC22WG5.5232) (j3.2006) Ballot on draft DTS Message-ID: In-Reply-To: <20140418184256.B9AAF358553@www.open-std.org> References: <20140312154430.1B7899EB083@www.open-std.org> <20140415075245.363AC3583C0@www.open-std.org> <20140418184256.B9AAF358553@www.open-std.org> X-Mailer: Prayer v1.3.5 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: owner-sc22wg5@open-std.org Precedence: bulk On Apr 18 2014, Damian Rouson wrote: >On Apr 15, 2014, at 12:35 AM, Malcolm Cohen wrote: >> >> In particular, (1) the collectives CO MAX, CO MIN, CO REDUCE, CO SUM, >> should be split into two forms, one with RESULT, one without. The one >> with RESULT should have SOURCE as INTENT(IN), the one without should >> have SOURCE as INTENT(INOUT). RESULT must not be optional. The SOURCE >> INTENT(IN) form should have no coarray restrictions on SOURCE. > > Is the reasoning here that there is a potential performance advantage > that can be preserved in the "INTENT(IN)" case? If so, I agree that > performance is paramount. If not, please explain the reasoning for > wanting two forms rather than having RESULT optional. I cannot speak for Malcolm, though I am pretty sure that I know his opinion, but I have tried to explain some much more important objections in my response. They are to do with variable definition context, read-only arguments/objects and software engineering. Modern Fortran is pretty good in this respect, and this specification drives a horse and cart through its basic model. Regards, Nick Mac;aren.