From owner-sc22wg5@dkuug.dk Thu Oct 2 21:20:21 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.10/8.9.2) id h92JKLSb027184 for sc22wg5-domo; Thu, 2 Oct 2003 21:20:21 +0200 (CEST) (envelope-from owner-sc22wg5@dkuug.dk) X-Authentication-Warning: ptah.dkuug.dk: majordom set sender to owner-sc22wg5@dkuug.dk using -f Received: from mail1.cray.com (mail1.cray.com [136.162.0.111]) by dkuug.dk (8.12.10/8.9.2) with ESMTP id h92JK94w027173 for ; Thu, 2 Oct 2003 21:20:14 +0200 (CEST) (envelope-from longb@cray.com) Received: from relayb.mw.cray.com (relayb.us.cray.com [192.168.252.110]) by mail1.cray.com (8.12.10/8.12.10/gw-1.2) with ESMTP id h8UJFnGE017815 for ; Tue, 30 Sep 2003 14:15:49 -0500 (CDT) Received: from saffron.us.cray.com (saffron.mw.cray.com [172.31.27.14]) by relayb.mw.cray.com (8.12.10/8.12.10/hub-1.3) with ESMTP id h8UJFmwO022294 for ; Tue, 30 Sep 2003 14:15:48 -0500 (CDT) Received: from cray.com (mh-dhcp-172-31-16-114 [172.31.16.114]) by saffron.us.cray.com (8.8.8/Cray-server-1.6-nhsmod011017) with ESMTP id OAA1628222; Tue, 30 Sep 2003 14:15:48 -0500 (CDT) Message-ID: <3F79D85F.70607@cray.com> Date: Tue, 30 Sep 2003 14:24:15 -0500 From: Bill Long Reply-To: longb@cray.com Organization: Cray Inc. User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SC22WG5 Subject: Vote on forwarding draft Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Cray-VirusStatus: clean X-Spam-Score: 0 () Sender: owner-sc22wg5@dkuug.dk Precedence: bulk Ballot on forwarding N1573 (J3/03-007R1) as the FCD for Fortran 2003. Deadline: 9 a.m. UK time on October 1st. Yes, with the following comments Signed Bill Long [544] The section heading "D.1" should be "D.2". D.1 already appears on [505]. There was some earlier discussion on restrictions on the use of an in associate constructs. Some of the issues involve technical content that we proposed to resolve through the interp process. However, there is one change that I think should go in right away (unless I've just missed it in the current draft). When we introduced pointers we had a means of specifying a memory location through two different names. With and we have also have multiple names for the same memory. In the pointer case we explicitly say that the ability to reference and define using the pointer name is tied to the ability to reference and define the target [83:23-24]. In the associate case, we spell out the connection for definition [161:22-23] but don't have the corresponding words for reference. I'd propose something like the following: [161:23+] If the is a that may not be referenced, the shall not be referenced. I think this covers a couple of important cases. If the is referenced before being defined in the construct, then the needs to be defined before that reference. Also, if the becomes undefined (deallocated, for example) then subsequent references using the are not allowed unless the or is defined in the mean time. Whether we want to prohibit deallocation of the outright is a topic for discussion later. Cheers, Bill -- Bill Long longb@cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120