From owner-sc22wg5@dkuug.dk Wed Jul 2 19:55:15 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h62HtFWl006808 for sc22wg5-domo; Wed, 2 Jul 2003 19:55:15 +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 h62Ht3Ec006803 for ; Wed, 2 Jul 2003 19:55:09 +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 h62Ht0Je005479 for ; Wed, 2 Jul 2003 10:55:00 -0700 Received: from math.jpl.nasa.gov (vsnyder@localhost) by math.jpl.nasa.gov (8.12.8/8.12.8/Submit) with ESMTP id h62Hsx7E005473 for ; Wed, 2 Jul 2003 10:55:00 -0700 Message-Id: <200307021755.h62Hsx7E005473@math.jpl.nasa.gov> X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 Reply-to: Van.Snyder@jpl.nasa.gov From: Van.Snyder@jpl.nasa.gov To: sc22wg5@dkuug.dk Subject: Straw votes to ponder concerning Modules TR Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 02 Jul 2003 10:54:59 -0700 Sender: owner-sc22wg5@dkuug.dk Precedence: bulk Questions concerning the Modules TR John has identified three questions concerning the Modules TR that need to be resolved before it can be completed. I've identified two more. John has suggested that some straw votes would provide some guidance. I agree that straw votes are useful for guidance, but I prefer that some thought go into the questions before the answers are sought. I believe the decisions that led to the changes to the TR at meeting 163 were taken hastily, and should be revisited. I would like you to think about these questions, and plan to cast ballots in straw votes on 14 July. I shall depart for ten days of holiday before the Dresden meeting on 17 July. ========================================================================== By what form of association should a submodule be related to its parent? -------------------------------------------------------------------------- The TR presently specifies host association. It is not ideal, but I consider it to be the least undesirable of the forms of association that the standard presently specifies. The arguments that I offer in favor of host association are 1. It is adequate in that any difference between the characteristics declared for a procedure in its interface body, and redeclared in its separate procedure body, can be detected, 2. It's a devil we already know, and 3. It doesn't require an addition to the standard. Lawrie has proposed an alternative in N1541 and N1542, that he calls "submodule association." He offers arguments in its favor there. ========================================================================== Should it be optional, prohibited or required to redeclare the characteristics of a module procedure that has separate interface in its body? -------------------------------------------------------------------------- The argument to require redeclaration is that this is the way Modula-2 and Ada do it. It would also simplify things. The argument against required redeclaration is that it met with substantial resistance when I proposed the separation of interface and implementation at the Lafayette meeting (the one hosted by Baker Kearfott). ========================================================================== Should it be possible to put a separate procedure body in the same module or submodule as its interface body? -------------------------------------------------------------------------- People have wanted to have interface bodies for module procedures, even before submodules were seriously considered. There is no technical reason for it to be more difficult to have interface and body in the same program unit, than to require them to be in different program units. ========================================================================== Should the interface body for a module procedure that has a separate body automatically access its environment by host association? -------------------------------------------------------------------------- The argument pro is the same as the argument that interface bodies for external procedures should not: The interface body and procedure body ought to have the same rules. The argument con is that it would be an exception to the present general rule that interface bodies do not access their environment by host association. ========================================================================== What syntax should be used to indicate that a module procedure has a separate interface body? -------------------------------------------------------------------------- The first draft of the TR proposed that the parent and descendant program units have additional sections, analogous to the contains section of a module. It would be allowed to have any number of these sections, and any number of contains sections, in any order after the specification part. In the parent program unit, it is specified in which submodule the procedure body is to be found. This aids maintenance, but it is an implementation detail. A cascade could result if one rearranges the assignment of procedure bodies to submodules. Therefore, in the specified submodule, one could delegate the definition of the procedure body to one of its descendant submodules, etc. The overwhelming response to the initial proposal was that it was too complicated. I therefore set out to develop the simplest proposal I could imagine. I cannot think of anything that is workable and yet simpler than putting a distinguishing keyword, the same keyword, in the prefix of the subroutine or function statements that introduce the interface body and the procedure body. In the current draft, that keyword is SEPARATE, meaning that the interface body and procedure body are separate. This is different from the decisions taken at j3 meeting 163. In reviewing the history of this project, I was surprised to realize that I had at first been urged to make the proposal simpler, and then to make it more complicated. I therefore now believe the decisions at meeting 163 to have been taken hastily. While you ponder this question, if you wish to propose something that is qualitatively differerent from what is in the current draft, ask yourself two other questions: 1. Is what I propose more complicated? 2. If so, is there a compelling reason for the complication? If you answer yes to these questions, please offer your colleagues good reasons. ==========================================================================