From owner-sc22wg5@dkuug.dk Thu Jul 10 21:59:16 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h6AJxGdg062326 for sc22wg5-domo; Thu, 10 Jul 2003 21:59:16 +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 h6AJx7Ec062318 for ; Thu, 10 Jul 2003 21:59:11 +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 h6AJwx4G014342; Thu, 10 Jul 2003 14:58:59 -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 h6AJwwoU019158; Thu, 10 Jul 2003 14:58:58 -0500 (CDT) Received: from cray.com (cf-vpn-192-168-239-5 [192.168.239.5]) by saffron.us.cray.com (8.8.8/Cray-server-1.6-nhsmod011017) with ESMTP id OAA500091; Thu, 10 Jul 2003 14:58:53 -0500 (CDT) Message-ID: <3F0DC72B.6010900@cray.com> Date: Thu, 10 Jul 2003 15:06:03 -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.2860) Nesting of Submodules References: <200307082322.h68NMJkX048431@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: >The reason for the Modules TR in the first place is that Fortran is >deficient in its support for really large programs, so let's not >consciously and intentionally insert any birth defects that actively >limit facilities for really large programs. > I agree that support for large programming projects should be a primary focus for Fortran. However, I don't believe that prohibiting submodules of submodules limits this ability. See below. > >In my view, the only reason for putting a limit on the height of a >submodule tree is an assumption that everybody else is so stupid that >they would routinely do things that we would never do ourselves, and then >blame us and the standard for allowing it. The standard allows lots of > Do not underestimate the ability of programmers to do stupid things. They write programs in C++, don't they? Besides this reason, simplicity of the standard and the compiler implementation are other reasons to limit the height of the tree. > >I agree with Bill's analysis of what would happen if one had a tree of >submodules with a height of ten. It is, however, extremely unlikely that >a submodule would have more than three ancestors in practice. The usual >situation will be one: the module. If the module has two submodules, and >each submodule has two submodules, a submodule tree of height ten has >1023 or 2047 program units, depending on your definition of "height", and >far more if the module or some submodules have more than two submodules. > >An author of a module with a submodule tree of height ten deserves what >happens. So also does an author of a program with 100,000 procedures. > The author of such a program is not the only potential victim. The compiler vendor who gets the program as a "test case" will end up wasting a lot of time sorting out the mess. So will the poor slob who inherits the program after the original author was fired for writing bad code. Either of these groups has a right to curse the standard for allowing this in the first place. > > >The user who has to cope with such a monstrosity will groan and curse >himself (or his colleagues) for creating it, but it is unlikely he will >curse the standard for allowing it to be created. The user who really >needs such a monstrosity will surely curse us if we prohibit it, just as >users who really really need ten-dimensional arrays curse us. Sure there > I'd claim that such a "need" does not exist for the submodule case. (Higher dimension arrays would seem like a potential candidate for a future standard revision.) >are workarounds for multidimensional arrays (derived types), and there >would be if we limited submodule tree height (make stuff public), but why >limit it at all? > >My recommendation to those who wish to avoid the pain of such >monstrosities is DON'T MAKE THEM. > And for the benefit of the other victims, I'd propose DON'T LET THEM. > >If a submodule can have more than one ancestor, the processor is probably >simpler without a limit than with one: I suspect most developers would >put the stuff that climbs the tree to the module in a loop, not replicate >it as many times as the maximum height the standard allows. The same >argument applies to the debugger. > >If we absolutely must have a limit, and I see no reason for one other >than a desire to prohibit other people from doing something you would >never do yourself, we should allow at least three levels of submodules. > >Here's why. > >For a module with several procedures that share some stuff, but that the >author wants to take care it could be reorganized without triggering a >cascade, submodules may reasonably need two ancestors: the module, and an >intermediate submodule where the shared stuff that shouldn't affect the >interface is put. If we require an explicit specification in the >interface of where the procedure body is, the intermediate level would >also include statements to indicate "The module lied; procedure X is in >submodule Y, not here". > We already have a way to deal with this situation. The shared stuff can be put in a separate (normal) module that is used by all the participating submodules. This is actually more flexible since other submodules can join the sharing pool by simply adding a USE statement, rather than rearranging the branches in a submodule tree. The USE approach also allows submodules to be members of multiple sharing pools, which is not possible with the multi-level tree approach. The shared module is unrelated to the parent of the submodules, so does not affect the compilation cascade benefits of submodules. Since putting shared stuff in a module is already the usual programming practice, it would seem likely that users would use this approach anyway, rather than using layers of submodules. Why invent a second mechanism to do something that can already be done better with existing language constructs? > >In an extreme case, three ancestors might be necessary. The first >submodule would merely be used for indirection so the module wouldn't >need changing if the assignment of procedure bodies to submodules is >changed. The second level would be used to partition shared stuff among >groups of third-level submodules. > This argument depends on the idea of having the parent specify which submodule contains a procedure body. I think this should not be done in the first place, avoiding the usefulness of the extra submodule layer, and also avoiding the "The module lied, ..." problem noted above. 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