From owner-sc22wg5@dkuug.dk Wed Jul 9 01:22:18 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h68NMI78048420 for sc22wg5-domo; Wed, 9 Jul 2003 01:22:18 +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 math.jpl.nasa.gov (math.jpl.nasa.gov [137.79.7.57]) by dkuug.dk (8.12.8p1/8.9.2) with ESMTP id h68NM7Ec048415 for ; Wed, 9 Jul 2003 01:22:14 +0200 (CEST) (envelope-from vsnyder@math.jpl.nasa.gov) Received: from math.jpl.nasa.gov (localhost.localdomain [127.0.0.1]) by math.jpl.nasa.gov (8.12.8/8.12.8) with ESMTP id h68NM5Jh008305 for ; Tue, 8 Jul 2003 16:22:06 -0700 Received: from math.jpl.nasa.gov (vsnyder@localhost) by math.jpl.nasa.gov (8.12.8/8.12.8/Submit) with ESMTP id h68NM5B6008301 for ; Tue, 8 Jul 2003 16:22:05 -0700 Message-Id: <200307082322.h68NM5B6008301@math.jpl.nasa.gov> X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 X-Exmh-Isig-CompType: comp X-Exmh-Isig-Folder: inbox Reply-to: Van.Snyder@jpl.nasa.gov From: Van.Snyder@jpl.nasa.gov To: sc22wg5@dkuug.dk Subject: Re: (SC22WG5.2858) Nesting of Submodules Mime-Version: 1.0 Content-Type: text/plain Date: Tue, 08 Jul 2003 16:22:05 -0700 Sender: owner-sc22wg5@dkuug.dk Precedence: bulk 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. 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 things that I would never do, like nesting 50 execution constructs. But I do not automatically assume that everybody else is so stupid that they would gleefully nest IF's and DO's 50-deep, or that if they did it would somehow hurt me. The standard doesn't have a limit on nesting of execution constructs, and I don't think it needs one. I don't think the TR needs a limit on the height of a submodule 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. Fortunately (because it's sometimes necessary to write a really big program) the standard doesn't limit how many program units a program can have. The difficulty of writing a makefile for a submodule tree of height ten is not qualitatively different from writing a makefile for a program with 1023 modules. Your perl script, or whatever you use to hunt for USE and INCLUDE, would also need to find SUBMODULE statements. Big deal. Even if you do it by hand, it's not really different. 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 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. 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". 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. A need for anything more than three levels of submodules is extremely unlikely. If we don't require an explicit specification in the interface of where the procedure body is, two levels of submodules is probably enough, as an intermediate level strictly for indirection wouldn't be needed. No matter what number we choose, the words are simple: A submodule shall not have more than ancestors. If <> is reflexive and we don't require an explicit specification in the interface of where the procedure body is, should be 3. If <> isn't reflexive and we don't require an explicit specification in the interface of where the procedure body is, should be 2. If <> is reflexive and we do require an explicit specification in the interface of where the procedure body is, should be 4. If <> isn't reflexive and we do require an explicit specification in the interface of where the procedure body is, should be 3. In the 1 July draft of the TR, <> is not reflexive. -- Van Snyder | What fraction of Americans believe Van.Snyder@jpl.nasa.gov | Wrestling is real and NASA is fake? Any alleged opinions are my own and have not been approved or disapproved by JPL, CalTech, NASA, Sean O'Keefe, George Bush, the Pope, or anybody else.