From owner-sc22wg5@dkuug.dk Thu Jul 10 22:59:51 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h6AKxpqV062677 for sc22wg5-domo; Thu, 10 Jul 2003 22:59:51 +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 h6AKxgEc062671 for ; Thu, 10 Jul 2003 22:59:46 +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 h6AKxeJh006753 for ; Thu, 10 Jul 2003 13:59:40 -0700 Received: from math.jpl.nasa.gov (vsnyder@localhost) by math.jpl.nasa.gov (8.12.8/8.12.8/Submit) with ESMTP id h6AKxeQ3006749 for ; Thu, 10 Jul 2003 13:59:40 -0700 Message-Id: <200307102059.h6AKxeQ3006749@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.2866) Nesting of Submodules Mime-Version: 1.0 Content-Type: text/plain Date: Thu, 10 Jul 2003 13:59:40 -0700 Sender: owner-sc22wg5@dkuug.dk Precedence: bulk I wrote: >An author of a module with a submodule tree of height ten deserves what >happens.... >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.... and Bill Long commented: ! 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. If you plan for it in advance, and process it with loops, and write careful loop invariants and check them (as Eiffel will do for you automatically), you can prove in advance that it will work. Testing will then verify that you haven't had a finger malfunction. ! 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. They have the right to curse the standard for any reason they like. But this is a red herring. I have never seen any complaint in any newsgroup or any mailing list that the limits in the standard are too large. I have seen plenty of complaints that we don't allow enough dimensions, or long enough lines, or enough lines in a statement. Putting in any limit almost always leads to complaints that it's too small. >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.... ! 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.... Why invent a second mechanism to do ! something that can already be done better with existing language ! constructs? The separate-module solution is only "better" if you're happy that all of the stuff shared among invisible submodules becomes public. Putting it in an intermediate-level submodule allows it to be even more private than private. A second mechanism isn't always worthless redundancy. Sometimes it's the right tool. I'm sure that I could disassemble and reassemble my car engine with a hammer and a screwdriver. After I'm done, the bolt heads would be well munged, and it probably wouldn't work. I'd much rather have a set of sockets and a torque wrench. Public doesn't just mean "Oh, gee, somebody who's not in my club might change it (or look at it)." It also means "Where the hell is this thing used?" Modula-2 requires either the equivalent of ONLY or explicit qualification of module entities with module names. Ada-83 didn't do this, allowing WITH (equivalent to our USE) and USE (meaning "package entities don't need to be qualified by package names"); this was very quickly (i.e. well before the public comment period for Fortran 90) recognized to be a mistake. Fortran 90 failed to follow the lead of Modula-2, or heed the well-known experience of the Ada community. What this long story is leading to is that by allowing USE without ONLY, the standard has made "grep" not really useful for finding "Where the hell is this thing used?" It's not that it doesn't find it; the problem is that it also finds every other irrelevant thing that has -- or contains -- the same name. Putting really really private things into an intermediate level of a submodule hierarchy limits their visibility, and thereby reduces lifetime costs. By the way, Ada has three levels: The package spec, the package body, and library subunits. Ada programmers who need to write large packages find library subunits indispensible. They put things that need to be shared among library subunits in the package body, not in a different package spec. We can learn from their experience, instead of ignoring it (again). Because package spec, package body, and library subunits are different things, Ada processors can't handle them with a loop. They need separate code for each beastie. The Modules TR proposes only two things, which are much more alike to each other than any two of the beasties Ada provides. What the Modules TR is proposing is simpler than what Ada provides; even so it is more useful, because of its flexibility. The Modules TR addresses exactly the problems that the Ada community has had -- and their tools were more powerful in 1983 than what we now have in Fortran 95. We shouldn't cripple our proposed new facility with artificial limitations that other communities have already found to be undesirable. -- 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.