From owner-sc22wg5@open-std.org Wed Nov 12 10:13:51 2008 Return-Path: X-Original-To: sc22wg5-dom7 Delivered-To: sc22wg5-dom7@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id 46FABCA343B; Wed, 12 Nov 2008 10:13:51 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by www2.open-std.org (Postfix) with ESMTP id 70B8EC178D9 for ; Wed, 12 Nov 2008 10:13:49 +0100 (CET) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:39305) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:nmm1) id 1L0BnJ-0007zi-0l (Exim 4.70) for sc22wg5@open-std.org (return-path ); Wed, 12 Nov 2008 09:13:49 +0000 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1L0BnJ-0006SJ-7K (Exim 4.67) for sc22wg5@open-std.org (return-path ); Wed, 12 Nov 2008 09:13:49 +0000 Received: from [83.67.89.123] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.1); 12 Nov 2008 09:13:49 +0000 Date: 12 Nov 2008 09:13:49 +0000 From: "N.M. Maclaren" To: WG5 Subject: Re: [ukfortran] (SC22WG5.3664) (j3.2006) N1755: Request for new features from MPI Forum Message-ID: In-Reply-To: <20081112001017.26EB3C178D6@www2.open-std.org> References: <49137AD3.1070402@lrz.de> <20081111224927.8201CC178D9@www2.open-std.org> <20081111234923.517C5C178D6@www2.open-std.org> <20081112001017.26EB3C178D6@www2.open-std.org> X-Mailer: Prayer v1.3.1 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: owner-sc22wg5@open-std.org Precedence: bulk On Nov 12 2008, Aleksandar Donev wrote: > >> Pretty much >> completely incompatible with the implications of volatile. > > What implications are those exactly. Please be specific. The VOLATILE > attribute applies if the object is referenced by means outside of the > program. It does not have to be changed (defined). Why is that > incompatible with INTENT(IN). Aargh! No! C 'const'! It has NOT been a success - in fact, to describe it as a paving slab on the road to hell would be fair. [ Yes, I am referring to the saying that the road to hell is paved with good intentions. ] In Fortran, as in traditional languages, the purpose of constraints is so that the processor AND programmer can rely on certain guarantees. Such as, when debugging, I know that an INTENT(IN) variable cannot change unless I also have a much more serious error that trashes memory. One of the reasons that the volatile concept in all of its incarnations is such a problem that it means that such constraints still bind the programmer but do not provide the guarantees any longer. >And more importantly, why is ASYNCHRONOUS different. Because ASYNCHRONOUS never allows the value to change from one defined value to another defined value without the programmer explicitly doing it. > Similar stuff for the VALUE attribute. The VALUE attribute and VOLATILE > together make perfect sense, if the volatility is restricted only to > inside the routine. The volatility applies to the anonymous copy of the > actual, once the routine finishes, the changes are thrown out. What is > wrong with that? Nothing. If that were what Fortran specified. But it isn't. I can't see much point in replacing one simple constraint by a much more complicated one, in order to provide a feature that few people will ever want to use! But I was not involved in the decision, so that is a personal view. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1@cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679