From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Mon Mar 24 21:48:21 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 435389DB115; Mon, 24 Mar 2014 21:48:21 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by www.open-std.org (Postfix) with ESMTP id DB4B2358700 for ; Mon, 24 Mar 2014 21:48:19 +0100 (CET) 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]:59689) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:nmm1) id 1WSBn9-0007ue-qv (Exim 4.82_3-c0e5623) for sc22wg5@open-std.org (return-path ); Mon, 24 Mar 2014 20:48:19 +0000 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1WSBn9-0000AS-Aa (Exim 4.72) for sc22wg5@open-std.org (return-path ); Mon, 24 Mar 2014 20:48:19 +0000 Received: from [87.113.109.128] by old-webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.5); 24 Mar 2014 20:48:19 +0000 Date: 24 Mar 2014 20:48:19 +0000 From: "N.M. Maclaren" To: "sc22wg5@open-std.org" Subject: Re: [ukfortran] (SC22WG5.5196) (j3.2006) Ballot on draft DTS Message-ID: In-Reply-To: <20140324160849.220FA356F90@www.open-std.org> References: <20140312154430.1B7899EB083@www.open-std.org> <20140324133031.CC99D35856F@www.open-std.org> <20140324160849.220FA356F90@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 Mar 24 2014, Bill Long wrote: >> >> Events.2) This TS introduces a facility that is arguably in conflict >> with Fortran 2008 page 23:1-2, and is not described as processor > >23:1 is a subclause title. 23:2 is the following text: > > In descriptive text, an equivalent English word is frequently used in > place of a syntactic term. Particular state- > >I'm having trouble understanding how this is relevant. Mea culpa. Brain failure due to overload. Fortran 2008 1.5 paragraph 1. Having a defined interpretation according to the standard. >> Collectives.1) This TS introduces a conflict with Fortran 2008's concept >> and specification of variable definition context. This is definitely >> fixable, but may need significant changes to the collectives. > >It would be simpler to fix this in 16.6.7. Whatever. My point is that it is a show-stopper as it stands. Depending on what is proposed, it may still be one. >> General.1 and General.2) This TS should be explicitly removed from >> consideration for inclusion in the next Fortran standard (see N1979), >> because it will probably be be infeasible to specify a data consistency >> model by the deadline for the first CD ballot, and there is very >> unlikely to be sufficient implementation and user experience. > > It today's environment, vendors are usually unwilling to implement > language features until after the standard is passed. ... That isn't relevant to my point, which is (a) whether the specification is logically consistent and (b) whether it is reasonably efficiently implementable without special hardware or operating system support. We have grounds to be certain (sic) of either. > Implementing EVENTS is straightforward (arguably trivial) if atomics are > already available, ... Not and delivering "a defined interpretation" (e.g. ensuring that example A.2.1 will make progress). An atomic set in segment A on image P may not become visible to segment B in image Q until segment A is ordered after segment B. Regards, Nick Maclaren.