From owner-sc22wg5@dkuug.dk Mon Jun 23 11:20:11 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h5N9KBGB045780 for sc22wg5-domo; Mon, 23 Jun 2003 11:20:11 +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 inf.rl.ac.uk (nfs7.inf.rl.ac.uk [130.246.72.7]) by dkuug.dk (8.12.8p1/8.9.2) with ESMTP id h5N9K7Ec045775 for ; Mon, 23 Jun 2003 11:20:07 +0200 (CEST) (envelope-from j.k.reid@rl.ac.uk) Received: from numerical.cc.rl.ac.uk (numerical [130.246.8.23]) by inf.rl.ac.uk (8.11.6+Sun/8.8.8) with ESMTP id h5N9I9D00276 for ; Mon, 23 Jun 2003 10:18:09 +0100 (BST) Received: from rl.ac.uk (jkr.cse.rl.ac.uk [130.246.9.202]) by numerical.cc.rl.ac.uk (8.8.8+Sun/8.8.8) with ESMTP id KAA27825 for ; Mon, 23 Jun 2003 10:28:55 +0100 (BST) Message-ID: <3EF6C763.603@rl.ac.uk> Date: Mon, 23 Jun 2003 10:24:51 +0100 From: John Reid Reply-To: j.k.reid@rl.ac.uk Organization: Rutherford Appleton Laboratory User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: WG5 Subject: Re: (SC22WG5.2798) Directions for Modules TR Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-sc22wg5@dkuug.dk Precedence: bulk -------- Original Message -------- To: longb@cray.com cc: sc22wg5@dkuug.dk Subject: Re: (SC22WG5.2798) Directions for Modules TR In-Reply-To: Message from Bill Long of "Fri, 20 Jun 2003 19:30:04 CDT." <3EF3A70C.4010503@cray.com> Mime-Version: 1.0 Content-Type: text/plain Date: Fri, 20 Jun 2003 19:45:25 -0700 From: Van Snyder > I'm not sure the rejection of SEPARATE was tied to the prefix issue as > much as not liking the word at all. This is definitely the case. I believe that SEPARATE was rejected hastily just because some folks didn't like the word on Thursday morning at meeting 163. I and a few others have thought about this a great deal. The nearly complete lack of discussion prior to meeting 163 suggests that most of those who voted against SEPARATE and in favor of the dog's breakfast we currently have actually didn't think much about this until Thursday morning in the meeting. > SEPARATE, as well as FORWARD (which is even worse in my opinion) are > words that denote a spatial distinction. I would prefer words that > indicated what a section of code is supposed to *be* rather than > where it is. This is why I prefer the IMPLEMENTS proposal. I disagree with this analysis (except the part about FORWARD being worse than SEPARATE). It simply demonstrates that we need to be careful to define precisely how we use common-usage words, and how we want the reader to think about them. I don't think of SEPARATE as meaning primarily that the reader has to look elsewhere. I chose SEPARATE because it is exactly the right word: It tells both the reader and processor that the interface and implementation are expressed separately. It doesn't say "where," it says "what." I see no point in piling on unnecessary complexity in the hope that a clueless reader, who doesn't already have enough context to see the difference between an interface and an implementation, will "get it." He has such deep problems that it is essentially irrelevant to him how we indicate that the interface and implementation are separately expressed. > There have been two objections to this proposal so far (both from Van). > One was trivial. The other was that the lack of a prefix word in the > submodule does not provide a prefix to be used in the interface in the > parent, implicitly assuming that a prefix is needed in the parent. I > don't see this as a reason to reject the IMPLEMENTS idea, but rather a > reason to develop a better solution in the parent. I didn't object specifically to the IMPLEMENTS idea, except if it is proposed to allow only one IMPLEMENTS section and one CONTAINS section, with a specific ordering requirement, say IMPLEMENTS first and CONTAINS second. I did not see this as a trivial objection. I will not do a TR that has this monstrosity. Assuming it is seriously proposed to have any number of IMPLEMENTS and CONTAINS sections in any order, the only appeal I see for an IMPLEMENTS section as opposed to a prefix is that one could say it once for a group of subprograms. This is not a step forward for me. It could put notice of the fact that a subprogram is not complete at some distance from its body. In my work, I would put IMPLEMENTS ahead of every subprogram, to make it clear to the reader that the procedure's interface is elsewhere, and then wonder why IMPLEMENTS isn't in the subprogram header, and spelled more sensibly. Taken in conspiracy with CONTAINS, IMPLEMENTS provides other opportunities for confusion. It's clear that CONTAINS means "this scoping unit contains others." So, if we have an IMPLEMENTS section followed by a CONTAINS section, does the CONTAINS imply the following procedures are contained within the IMPLEMENTS section? I find this to have more potential to confuse a reader than putting a prefix on a subprogram header. A module or submodule will be able to contain both subprograms of the currently defined variety and implementations. A separate section with a name different from CONTAINS implies that the module somehow doesn't contain the implementation bodies. The objection that Bill thinks is more serious is actually farther down my list of objections. I just like the economy of a single word. > I don't recall why SUBMODULE INTERFACE was rejected before, but at > that would be one option to consider. At least it connects to the > idea of submodules. SUBMODULE INTERFACE was rejected because the procedure body might be in the module. > If you prefer something attached to the subprogram statement rather than > the interface statement, something similar to the bind(c) syntax might > work, such as > > interface > subroutine sub(x,y),implemented_in(submodule_name) > ... > end interface > > Either of these options communicate to the user what is going on more > clearly that SEPARATE or FORWARD. The implemented_in(submodule_name) > would allow for an extra measure of verification by the compiler that > you are doing what you intended. It also might make the name mangling > algorithm easier. Doesn't this say where it is, not what it is? Processors already use the program unit where a module's interface is defined for name mangling. Would you go to the extra work to do something different if it wasn't really necessary? Beyond that, saying where the body is defined is simply a bad idea. It assigns bodies to submodules during the design of a module's interface, which assignment is more likely to be a guess than a well-thought-out decision. If one later discovers good reasons to move things around, the module has to be recompiled, which results in a recompilation and recertification cascade. The interface should be the interface, and as little else as possible. The least else I can think of is adding one word to say "This isn't the interface for an external procedure." If we take off the "(submodule_name)" from your proposal and change "implemented_in" to something sensible that doesn't want a "so where is it" afterward -- such as "implemented_separately" -- we have a bare word with no parentheses or other clutter, which could just as easily be put into the . This is a bit of a long-winded way of saying "separate". > I'm not necessarily claiming that the above options are the best ones. > However, SEPARATE and FORWARD were rejected before and I don't see the > reasons for that rejection as having changed. We need something better. Well, FORWARD is what was developed at meeting 163, not what was rejected. Rember that in the first paragraph of this tirade I asserted that the change of direction at meeting 163 was hastily done. I think those decisions should be thoughtfully reconsidered. -- 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.