From owner-sc22wg5@dkuug.dk Tue Jul 8 20:08:42 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h68I8gdG046515 for sc22wg5-domo; Tue, 8 Jul 2003 20:08:42 +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 h68I8SEc046508 for ; Tue, 8 Jul 2003 20:08:36 +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.9/gw-1.2) with ESMTP id h68I8J4G015354; Tue, 8 Jul 2003 13:08:20 -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 h68I8IF7012790; Tue, 8 Jul 2003 13:08:18 -0500 (CDT) Received: from cray.com (cf-vpn-192-168-239-28 [192.168.239.28]) by saffron.us.cray.com (8.8.8/Cray-server-1.6-nhsmod011017) with ESMTP id NAA343961; Tue, 8 Jul 2003 13:08:12 -0500 (CDT) Message-ID: <3F0B0A38.3080807@cray.com> Date: Tue, 08 Jul 2003 13:15:20 -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.2850) Straw votes to ponder concerning Modules TR References: <200307021755.h62HtGgM006819@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: >Questions concerning the Modules TR > >John has identified three questions concerning the Modules TR that need to >be resolved before it can be completed. I've identified two more. > And I would suggest one more, below. >========================================================================== > >By what form of association should a submodule be related to its parent? > >-------------------------------------------------------------------------- > > > I agree with the current proposed host association for the reasons mentioned by Van, especially the virtue of not adding yet another form of association to the standard. In addition, I think is is desirable to allow users the freedom of reusing names for local objects in the submodule. Lawrie sees this as a negative, but I see it as a positive. (I do agree with Lawrie, though, that Brisbane is a nice place.) >========================================================================== > >Should it be optional, prohibited or required to redeclare the >characteristics of a module procedure that has separate interface in its >body? > >-------------------------------------------------------------------------- > > > I'd prefer to require redeclaration. This is the simplest in terms of syntax, and avoids potential reader confusion in the case of subroutines with no arguments. It also makes it a lot easier to read and debug code. Even of the final rule turns out the other way, I'd always include the redeclaration for that reason. Prohibiting redeclaration is not acceptable, > >========================================================================== > >Should it be possible to put a separate procedure body in the same module >or submodule as its interface body? > >-------------------------------------------------------------------------- > > > This runs counter to the whole objective of submodules - to get the interface and procedure body into separate files. However, I do see a possible use for this general idea, but think the rule change should be disconnected from submodules. We should just allow an interface to be specified more than once as long as the various specifications agree. This would make idea of module evolution easier to implement. In the initial implementation the user would write module procedures and also matching interfaces. A later transition to submodules would just involve cutting the procedure body out and pasting it into the submodule. (See below a proposed simplification to the TR proposal that would make this even more direct.) > >========================================================================== > >Should the interface body for a module procedure that has a separate body >automatically access its environment by host association? > >-------------------------------------------------------------------------- > > > No. I prefer no changes to the rules for interface bodies. See below. > >========================================================================== > >What syntax should be used to indicate that a module procedure has a >separate interface body? > >-------------------------------------------------------------------------- > > > I would like to propose an alternative approach that avoids this debate and that has an added functional benefit that I believe has been overlooked. I propose that we make no change to the syntax for any of interface statements, interface bodies, or subroutine/function statements. The only new syntax change it to add the SUBMODULE and END SUBMODULE statements in their currently proposed forms. I see this as a significant simplification. The parent module would contain an ordinary interface body, and the submodule would contain an ordinary procedure definition. The submodule is required to verify that the interface in the parent matches the definition in the submodule. If the procedure is defined in the module containing the interface, then this just is a special case of interface respecification and has nothing to do with submodules. Procedures defined in a submodule have the characteristics of external procedures (i.e. no name mangling). This solves what has been one of the main problems with module procedures - that a caller needs to have a USE statement. This has been a roadblock to repackaging legacy libraries to use the host association and argument verification facilities available with modules. By putting the actual procedure body in a submodule, the name is not mangled and legacy codes can call the procedure without requiring a USE statement. New codes can USE the parent module and take advantage of argument checking and other module facilities. Module evolution becomes trivial with this implementation. A module is originally written with both interface blocks and contained module procedures. Migration to submodules later involves cutting the procedure definition out of the parent module, and pasting it into a submodule that references the parent. No editing of either the interface or the procedure is needed. Similarly, a library of legacy subprograms could be pasted into one or more submodule(s) and a separate parent module written with interfaces for these routines. No editing of the actual library routines is needed. I believe this alternative approach to submodules offers several advantages over the current proposals: 1) It is simpler for users to understand since it mainly relies on existing syntax and concepts. 2) It is easier to implement. 3) There would be fewer, and more localized, changes to the standard. 4) It adds the useful feature of combining unmangled procedure names with module facilities. ================================================================= I believe an additional question is reasonable for a straw vote: Should a submodule be allowed as a parent of another submodule? ------------------------------------------------------------------------------- I vote NO on this. I think that allowing multiple layers of submodules is a gratuitous complication that serves no real purpose. Further, there is the usual problem of specifying that something is allowed to be nested to unspecified levels: actual implementations are allowed to put a limit on the number of levels under the size and complexity exemption. This can limit portability. I'd prefer to avoid this issue from the start and say that the parent of a submodule must be a module. 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