From owner-sc22wg5@open-std.org Fri Feb 5 10:26:10 2010 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id B0EF3C3BA07; Fri, 5 Feb 2010 10:26:10 +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 E2D96C3BA06 for ; Fri, 5 Feb 2010 10:26:08 +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-2.csi.cam.ac.uk ([131.111.8.54]:55485) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:nmm1) id 1NdKRw-0007aT-1w (Exim 4.70) (return-path ); Fri, 05 Feb 2010 09:26:04 +0000 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1NdKRw-0005O7-Im (Exim 4.67) (return-path ); Fri, 05 Feb 2010 09:26:04 +0000 Received: from [83.67.89.123] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.2); 05 Feb 2010 09:26:04 +0000 Date: 05 Feb 2010 09:26:04 +0000 From: "N.M. Maclaren" To: longb@cray.com Cc: "Van.Snyder@jpl.nasa.gov" , fortran standards email list for J3 , sc22wg5 Subject: Re: [ukfortran] (SC22WG5.4155) (j3.2006) Question about our design for associate names Message-ID: In-Reply-To: <20100205053914.890D6C3BA06@www2.open-std.org> References: <20100205040451.A151BC3BA06@www2.open-std.org> <20100205053914.890D6C3BA06@www2.open-std.org> X-Mailer: Prayer v1.3.2 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: owner-sc22wg5@open-std.org Precedence: bulk On Feb 5 2010, Bill Long wrote: > >> Do we want to >> >> (1) add the restrictions to associate names >> (a) by way of an interp against 2003, >> (b) in 2008 and announce an incompatible change, or >> (c) in 2013 and announce an incompatible change, or >> (2) not add the restrictions? > >I would certainly vote for (2). It has two major advantages: It does >not change the current concept that associate constructs are just a >mechanism for creating aliases to simplify expressions, and, more >important, it would not suddenly invalidate existing codes. Yes. Keep it simple. While I dislike the way that pointers permit aliasing in constructs that would otherwise not allow it, I don't think that any more special cases would be helpful. I took a look at that area, from the point of view of teaching it, and decided not to! The current rules are already too complicated to explain in simple terms. If this were being tackled, I would prefer a more generic approach, such as a new attribute (say PURE), that would apply to POINTER and TARGET and remove almost all of the aliasing liberty (i.e. the rules for ordinary variables would apply). Obviously not for 2008, and I haven't thought this through, so it might not fly. Regards, Nick.