From owner-sc22wg5@dkuug.dk Wed Jun 25 01:26:08 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h5ONQ80h055601 for sc22wg5-domo; Wed, 25 Jun 2003 01:26:08 +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 h5ONPwEc055592 for ; Wed, 25 Jun 2003 01:26:03 +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 h5ONPplW010112; Tue, 24 Jun 2003 18:25:51 -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 h5ONPoV9010155; Tue, 24 Jun 2003 18:25:50 -0500 (CDT) Received: from cray.com (mh-dhcp-172-31-20-206 [172.31.20.206]) by saffron.us.cray.com (8.8.8/Cray-server-1.6-nhsmod011017) with ESMTP id SAA5073498; Tue, 24 Jun 2003 18:25:50 -0500 (CDT) Message-ID: <3EF8DF9F.9060103@cray.com> Date: Tue, 24 Jun 2003 18:32:47 -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: Richard Maine CC: sc22wg5@dkuug.dk Subject: Re: (SC22WG5.2808) Directions for Modules TR References: <200306210245.h5L2jPSY021832@math.jpl.nasa.gov> <200306232343.h5NNhQR1049761@dkuug.dk> <200306240017.h5O0HGFQ050176@dkuug.dk> <200306241453.h5OErNtC053210@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 Richard Maine wrote: >Aleksandar Donev writes: > > > I clearly remember that at meeting 164 some wanted to be > > able to put the body of the separate procedure in the *same* module. I, > > like you, see no point in this and think it should not be allowed, but > > cannot recall what arguments were put to the contrary. > >Did Bill say he saw no point in that? Well, perhaps. I might have >missed it. Anyway, I think it should be allowed...or more pertinently >I don't think it should be disallowed. The main reason is just >that it seems an arbitrary restriction with no particular purpose >or logic. Arbitrary restrictions are a complication and something >for users to memorize and question. > > > I guess I see this from a different perspective. We currently have a pretty simple and (once you get used to them) logical set of rules regarding procedures and interfaces. If the procedure is defined in a module it automatically provides an explicit interface, so you never write an interface block for a module procedure. If the procedure is defined outside the module you either provide an interface explicitly with an interface block or a USE, or you have an implicit interface. The distinction between procedures defined in the module and ones defined outside the module is clean and simple. If we now start allowing interfaces for procedures defined in the same module, we're asking people to unlearn the old rules and replace them with new rules. This is more confusing, not less confusing. In return, I don't see any benefit to the user for allowing this additional complexity. Quite to the contrary, more than once in this thread alternatives to the SEPARATE construct have been rejected based on wanting to allow this new feature. I see this as placing an unnecessary and artificial restriction on our options. If we require that 'separate' procedures are defined in submodules, and not where the interface block is specified, then we still have the old, simple rule in place - interfaces for procedures defined outside the module. I think that the fewest possible changes to the rules for modules results in the least confusion and the least for users to memorize and question. If it were not for the desire to have the names of submodule routine mangled, I don't see why we would need any special syntax in the parent module at all. The submodule procedures would be treated just like any other external procedure. The purpose of a submodule would simply to specifying where the interface information could be obtained (or verified). I have a second, more general objection to the trend I'm seeing. When I voted to go forward with the submodule TR, I was voting for the concept Van presented at J3 meetings that would allow users to avoid the compilation cascade problem. I was not voting for a additional collection of other features that may have been discussed in 1988. I really see merit in the submodule idea and want to see a clean and simple implementation. I do not want to see this turn into a vehicle for all the neat extra features that someone thinks might be related. While I'm on the simplification soap box, could we limit the number of generations to 2? Parents are always modules, and children are always submodules. Having submodules of submodules seems like an unnecessary complication. What purpose does it serve? 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