From owner-sc22wg5@dkuug.dk Tue Jun 24 00:24:54 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h5NMOsqx049099 for sc22wg5-domo; Tue, 24 Jun 2003 00:24:54 +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 h5NMOhEc049092 for ; Tue, 24 Jun 2003 00:24:48 +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 h5NMObJe003476 for ; Mon, 23 Jun 2003 15:24:37 -0700 Received: from math.jpl.nasa.gov (vsnyder@localhost) by math.jpl.nasa.gov (8.12.8/8.12.8/Submit) with ESMTP id h5NMObi6003472 for ; Mon, 23 Jun 2003 15:24:37 -0700 Message-Id: <200306232224.h5NMObi6003472@math.jpl.nasa.gov> X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: inbox To: sc22wg5@dkuug.dk Reply-to: Van.Snyder@jpl.nasa.gov Subject: Re: (SC22WG5.2801) Modules TR syntax In-Reply-To: Your message of "Sat, 21 Jun 2003 15:15:40 EDT." <200306211915.h5LJFofu037968@dkuug.dk> From: Van.Snyder@jpl.nasa.gov Mime-Version: 1.0 Content-Type: text/plain Date: Mon, 23 Jun 2003 15:24:37 -0700 Sender: owner-sc22wg5@dkuug.dk Precedence: bulk The strongest message I got after presenting the first draft of the Modules TR was "This is too complicated; go away; do it simpler; come back later." I've now made it as simple as I can, and the message appears to be "This is too simple; go away; do it more complicated; come back later." Aleks wasn't there to participate in the "Make it simpler..." message, but almost everybody else who's now saying "This is too simple..." was. I don't understand the mixed message. Do the committees have some complex eigenvalues? I hope the real parts aren't positive. I still have two fundamental questions about what I've proposed, and for which I haven't received even an attempt at an answer: 1. What is unworkable about using one word, THE SAME WORD, in the prefix of a separate interface body and a separate subprogram?, and 2. What is accomplished by proposals that are more complex than the simple proposal? Now for Aleksandar's letter. Last week I wrote: > >I got four not-very-convincing responses. and Aleksandar replied: > I have to say that your responses have not been very convincing > either..."I like to alphabeticize my procedures" hardly counts as one. It wasn't intended to be an argument on its own, but rather the essential point of a counterargument to the "One-IMPLEMENTS / one-CONTAINS section" proposal. A Multiple-IMPLEMENTS / Multiple-CONTAINS section proposal would allow a style equivalent a one-IMPLEMENTS and one-CONTAINS system, but not vice-versa. The only real argument is what's embodied in my two questions above, but if we must parry every thrust, how about the other objections I had? > First, a question for Lawrie, who wants to introduce submodule association: > A separate procedure can be in the same module, in which case it > accesses the module via host association. Do you propose to change this > for such procedures, so that redeclarations of module entities in the > procedure body mean something else? No. Lawrie's proposed new association would apply only between a submodule and its parent program unit. Procedures would continue to access their environments by host association. > Now, here is a summary of what I consider significantly better syntax > then the current draft, or Lawrie's proposal, but which tries to > account for those proposal's ideas and worries. Of course, all is > IMO, and others can decide the merit of it all. But you are correct > in assuming that not many will think about this before the meeting > itself :-( It doesn't account for my most important question: Why is a proposal that is more complex than necessary desirable? > MODULE My_Module > > IMPLEMENTATION INTERFACE > ! In this kind of interface host association is automatic > ! IMPORT is not allowed > INTEGER FUNCTION Function_1(x) > INTEGER :: x > END FUNCTION > REAL FUNCTION Function_2(x) > REAL :: x > END FUNCTION > END INTERFACE > > INTERFACE My_Generic > MODULE PROCEDURE :: Function_1, Function_2, Function_3 > ! These are all module procedures > ! We should allow here I believe in 260:27 > CHARACTER FUNCTION Function_4(x) ! External > IMPORT ! OK here > CHARACTER :: x > END FUNCTION > END INTERFACE > > IMPLEMENTS > ! Special association may apply within the IMPLEMENTS block > ! But they better be the same as in the SUBMODULE below! > ! I personally would prefer to keep host association for simplicity... > > IMPLEMENTATION PROCEDURE(Function_2) > ! No redeclaration at all > ! This is my preference, but not necessary > ! I would also agree with requiring full redeclaration > Function_2=x*x > END IMPLEMENTATION > > CONTAINS > > CHARACTER FUNCTION Function_4(x) > CHARACTER :: x > Function_4=x > END FUNCTION > > END MODULE > > SUBMODULE(My_Module) My_Submodule > ! Association rules with My_Module entities is to be determined > ! by Van and Lawrie bout > > IMPLEMENTS > > INTEGER FUNCTION Function_1(x) ! Full-redeclaration > ! Or no redeclaration as above > INTEGER :: x > Function_1=x*x > END FUNCTION > > END SUBMODULE > > Notice that I have used the work IMPLEMENT as the root of the two new > keywords, IMPLEMENTATION and IMPLEMENTS. This seems to me the most > natural choice. > > The only blot in this is that for the generic interface My_Generic, one > has to retype the names of the procedures Function_1, Function_2 etc. > But notice that their interface is only declared once, in the > IMPLEMENTATION INTERFACE. I consider this a minor annoyance, and will > propose generic interface merging for the next revision which will fix > this and other annoyances with generic interfaces. This isn't the only blot. Most importantly, it is more complicated than necessary. Another is that one cannot tell by looking at the subprogram header, in the complete redeclaration case, whether it is a complete subprogram, or the separate implementation part of a subprogram. One needs to search backward for the most recently previous occurrence of IMPLEMENTS or CONTAINS. My editor can't do this directly, so I'd need to search backward for one of them, write down the line number, go back to the interesting subprogram header, search backward for the other one, and compare line numbers. Each little irritation like this increases lifetime software ownership costs, the moreso when multiplied by the hundreds or thousands of subprograms in a big program. The situation is not quite so bad within an interface block because there's only one potentially distant thing that one would search backward for. Of course, one could write a separate interface block for each interface body, but it would be so much simpler to annotate the interface body, and not invent a new flavor of interface block. One might say "But you're proposing a new flavor of interface body; what's the difference?" The difference is that I am proposing to use exactly the same syntax to distinguish the new flavor of interface body from an ordinary one, and to distinguish an implementation for a procedure with a separate interface from an ordinary one: I am proposing one new mechanism, to be used in two places, instead of two or three new mechanisms. Do we really need to A. Invent a new variety of interface block, B. Allow the names of interface bodies in those interface blocks to be mentioned in generic interface blocks, C. Invent a new kind of section of a module, and D. Put a prefix on a subprogram header in that new section if the interface isn't redeclared? This is four mechanisms, compared to the one new mechanism I propose, which would be used in two places. It is exactly the sort or complexity, with different keywords, that was rejected in my original proposal. Here's an equivalent to Aleksandar's module, in the syntax I will propose in N1537: MODULE My_Module INTERFACE My_Generic SEPARATE INTEGER FUNCTION Function_1(x) INTEGER :: x END FUNCTION SEPARATE REAL FUNCTION Function_2(x) REAL :: x END FUNCTION MODULE PROCEDURE :: Function_3 CHARACTER FUNCTION Function_4(x) ! External IMPORT ! OK here CHARACTER :: x END FUNCTION END INTERFACE CONTAINS SEPARATE FUNCTION Function_2 Function_2=x*x END FUNCTION Function_2 END MODULE CHARACTER FUNCTION Function_4(x) CHARACTER :: x Function_4=x END FUNCTION SUBMODULE(My_Module) My_Submodule CONTAINS SEPARATE INTEGER FUNCTION Function_1(x) ! Full-redeclaration ! Or no redeclaration as above INTEGER :: x Function_1=x*x END FUNCTION END SUBMODULE Exclusive of comments and blank lines, this is 29 lines; Aleksandar's is 33. It introduces one new word instead of two. The new word appears only in one syntax rule. There is a new form of interface body instead of a new form of interface block. The names of the separate procedures are not mentioned redundantly in the generic interface block, because the separate interface bodies are declared therein. It does not introduce a new section for modules and submodules. It does not introduce a new variety of scoping unit -- an "implementation" that might be a subroutine or a function. If the implementation is for a function, it doesn't need a new place to mention the result variable, or new rules to get it from the interface body. -- 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.