From owner-sc22wg5@dkuug.dk Sat Jun 21 02:23:36 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h5L0NaTY031460 for sc22wg5-domo; Sat, 21 Jun 2003 02:23:36 +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.8p1/8.9.2) with ESMTP id h5L0NQEc031455 for ; Sat, 21 Jun 2003 02:23:31 +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.9/8.12.3/gw-1.14) with ESMTP id h5L0NDlW005556; Fri, 20 Jun 2003 19:23:14 -0500 (CDT) Received: from saffron.us.cray.com (saffron.mw.cray.com [172.31.27.14]) by relayb.mw.cray.com (8.12.9/8.12.6/hub-1.2) with ESMTP id h5L0NCn4006180; Fri, 20 Jun 2003 19:23:13 -0500 (CDT) Received: from cray.com (mh-dhcp-172-31-20-27 [172.31.20.27]) by saffron.us.cray.com (8.8.8/Cray-server-1.6-nhsmod011017) with ESMTP id TAA4597734; Fri, 20 Jun 2003 19:23:12 -0500 (CDT) Message-ID: <3EF3A70C.4010503@cray.com> Date: Fri, 20 Jun 2003 19:30:04 -0500 From: Bill Long Reply-To: longb@cray.com Organization: Cray Inc. User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Van.Snyder@jpl.nasa.gov CC: sc22wg5@dkuug.dk Subject: Re: (SC22WG5.2798) Directions for Modules TR References: <200306202321.h5KNLroJ030959@dkuug.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Cray-VirusStatus: clean Sender: owner-sc22wg5@dkuug.dk Precedence: bulk Van.Snyder@jpl.nasa.gov wrote: > >Bill recollected that more people disliked the IMPLEMENTATION ... END >IMPLEMENTATION bracket less than they disliked putting SEPARATE in procedure >headers. I regard the decision to go in this direction as a hurried >decision. I didn't like it at meeting 163, but I acquiesced. The more >I think about it, the more I dislike it. > > > I'm not sure the rejection of SEPARATE was tied to the prefix issue as much as not liking the word at all. SEPARATE, as well as FORWARD (which is even worse in my opinion) are words that denote a spatial distinction. I would prefer words that indicated what a section of code is supposed to *be* rather than where it is. This is why I prefer the IMPLEMENTS proposal. There have been two objections to this proposal so far (both from Van). One was trivial. The other was that the lack of a prefix word in the submodule does not provide a prefix to be used in the interface in the parent, implicitly assuming that a prefix is needed in the parent. I don't see this as a reason to reject the IMPLEMENTS idea, but rather a reason to develop a better solution in the parent. I don't recall why SUBMODULE INTERFACE was rejected before, but at that would be one option to consider. At least it connects to the idea of submodules. If you prefer something attached to the subprogram statement rather than the interface statement, something similar to the bind(c) syntax might work, such as interface subroutine sub(x,y),implemented_in(submodule_name) ... end interface Either of these options communicate to the user what is going on more clearly that SEPARATE or FORWARD. The implemented_in(submodule_name) would allow for an extra measure of verification by the compiler that you are doing what you intended. It also might make the name mangling algorithm easier. I'm not necessarily claiming that the above options are the best ones. However, SEPARATE and FORWARD were rejected before and I don't see the reasons for that rejection as having changed. We need something better. 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