From owner-sc22wg5@dkuug.dk Tue Jul 8 23:48:35 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h68LmZ6s047772 for sc22wg5-domo; Tue, 8 Jul 2003 23:48:35 +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 h68LmQEc047764 for ; Tue, 8 Jul 2003 23:48:30 +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 h68LmI4G020924; Tue, 8 Jul 2003 16:48:18 -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 h68LmHF7021293; Tue, 8 Jul 2003 16:48:17 -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 QAA354493; Tue, 8 Jul 2003 16:48:14 -0500 (CDT) Message-ID: <3F0B3DCA.5070806@cray.com> Date: Tue, 08 Jul 2003 16:55:22 -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: Craig Dedo CC: WG5 Mailing List Subject: Re: (SC22WG5.2857) Nesting of Submodules (Was: Straw votes to ponder concerning Modules TR) References: <200307021755.h62HtGgM006819@dkuug.dk> <200307081808.h68I8hxG046526@dkuug.dk> <200307081911.h68JBDLP046933@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 Craig Dedo wrote: > > > I disagree. There is a well known and proven solution to the > problem of nesting to unspecified levels. All we need to do is > specify a minimum number of levels, with the option of exceeding this > minimum. We do that in a number of other cases, e.g.: > * Number of array dimensions > * Number of characters per physical source line > * Number of physical source lines per logical source statement I think a closer analogy would be the number of nesting levels we allow for internal subprograms. In this case we specify a maximum number that a conforming program may not exceed, and by inference, a minimum number the compiler has to support. I believe that number is 1, which is what I prefer for submodules as well. > > The text is quite easy to write. We could say something like, "The > processor shall allow nesting of at least 100 submodules." Or, use > whatever other number you believe is reasonable. I'm not sure we define the concept of "nesting" in this context. Of course, the wording is even simpler for the one level case: "The parent of a submodule must be a module", or (as a compromise) for the two level case: "The parent of a submodule must be either a module or a submodule whose parent is a module" > > > Other than the nesting limit issue, are there any other > complications with nesting submodules? Yes, I believe so. Suppose you have a module, M, and 10 generations of submodules, S1,..., S10. 1) If the interface for a procedure, XXX, defined in S10 is visible, it must be specified in M. The compiler will have to find, in succession, the files containing S9, S8, ..., S1, before it will be able to locate the interface in M. If any of S9..S1 also specify interfaces for XXX (assuming we allow interface respecification) then all of those interfaces will need to be compared to the one in XXX for consistency. In addition, entities in S9..S1 will be available in S10 through host association. That is a lot of work for the compiler, which translates into slow compilation. The associated makefile and/or compiler command line options are going to be complicated as well. This is also a lot of implementation work for compiler vendors which means that the feature will be available to users later rather than sooner. I'd prefer simpler and sooner. 2) It is very difficult for a human to debug a program with this structure that was written by someone else. This is especially true if the files are scattered among several directories. 3) Significant effort will be required to rewrite debugging tools to understand this level of complexity. Probably they will not work correctly when the initial compiler implementations come out. 4) If, for example, S3 is changed, you will end up having to recompile all of S4..S10. S5 may have multiple children with a whole set of additional trees of submodules that have to be recompiled. Ironically, you've ended up creating a new compilation cascade problem. 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