From owner-sc22wg5@dkuug.dk Tue Jun 17 03:55:19 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h5H1tJnt005015 for sc22wg5-domo; Tue, 17 Jun 2003 03:55:19 +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 h5H1tAEc005010 for ; Tue, 17 Jun 2003 03:55:15 +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 h5H1t3Je005472 for ; Mon, 16 Jun 2003 18:55:03 -0700 Received: from math.jpl.nasa.gov (vsnyder@localhost) by math.jpl.nasa.gov (8.12.8/8.12.8/Submit) with ESMTP id h5H1t2aP005468 for ; Mon, 16 Jun 2003 18:55:03 -0700 Message-Id: <200306170155.h5H1t2aP005468@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 To: sc22wg5@dkuug.dk Subject: Modules TR Mime-Version: 1.0 Content-Type: text/plain Date: Mon, 16 Jun 2003 18:55:02 -0700 From: Van Snyder Sender: owner-sc22wg5@dkuug.dk Precedence: bulk You may remember that the direction I was going with the Modules TR before meeting 163 was rather like to where Lawrie wants to return. I wish to revisit some of the decisions taken at meeting 163. If I remember correctly, we put a bracketing construct around the implementation of a procedure that has its interface separate from its body because some folks didn't like the prefix SEPARATE. There was some sentiment for a prefix IMPLEMENTATION. After that was agreed, folks didn't like IMPLEMENTATION SUBROUTINE or IMPLEMENTATION FUNCTION, so we got a whole new bracketing construct. I'd like to return to having just a SEPARATE prefix, meaning "this body is separate from its interface." We also have a prefix FORWARD for an interface block. The prefix logically belongs on the interface body, which would allow us to mix other interface bodies, and MODULE PROCEDURE statements, together into a single generic interface block. If we put the prefix on the interface body instead of the interface block, it would be simpler to put the same prefix there and on the procedure's definition. I prefer SEPARATE, to mean "this interface is separate from the definition of the corresponding body." IMPLEMENTATION doesn't make sense for an interface body, and FORWARD doesn't make sense for the procedure's implementation. I find the simplification of getting rid of a bracketing construct, and having one prefix instead of two, to be attractive. Is there significant opposition to revisiting the questions: 1. Do we want the distinguishing prefix for a separate interface to be on the interface block or the interface body? 2. Do we want a bracketing construct around the implementation of a procedure that has its interface defined separately? 3. If we get rid of the bracketing construct, do we want the same or different prefixes in the interface body and implementation? 4. If we have the same prefix, is SEPARATE OK? IMPLEMENTATION is definitely the wrong word to put in the interface body, and FORWARD isn't quite right for the implementation -- although not as bad as putting IMPLEMENTATION in the interface body. I will prepare a draft assuming that the answers are (1) interface body; (2) no; (3) same; and (4) SEPARATE is OK, so long as the logic for it is explained unless I hear strident objections to revisiting these questions, or to my proposed answers to them, this week. I am a little bit uncomfortable with adding a new form of association, as Lawrie will propose in an alternative draft of the Modules TR. My discomfort does not arise so much from a new form per se, but rather from some trepidation that we may not get it right at first. For example, in reading Lawrie's draft the umpteenth time, I suddenly realized that his new "submodule association" can only apply between the scoping units of a parent and its child submodule. It's clear that a procedure has to access the scoping unit of its submodule by host association. Otherwise, it could not access type definitions, variable declarations, or other procedures within the submodule. In my revised draft, I will assume host association. A new form of association, which Lawrie calls "submodule association" would be easy to add. -- 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.