From owner-sc22wg5@dkuug.dk Wed Jul 9 16:44:59 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h69EixCV052144 for sc22wg5-domo; Wed, 9 Jul 2003 16:44:59 +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 mx1.liv.ac.uk (mx1.liv.ac.uk [138.253.100.179]) by dkuug.dk (8.12.8p1/8.9.2) with ESMTP id h69EiqEc052139 for ; Wed, 9 Jul 2003 16:44:54 +0200 (CEST) (envelope-from j.s.morgan@liverpool.ac.uk) Received: from mailhub5.liv.ac.uk ([138.253.100.157]) by mx1.liv.ac.uk with esmtp (Exim 4.14) id 19aGBb-0001HW-CC; Wed, 09 Jul 2003 15:44:47 +0100 Received: from localhost ([127.0.0.1] helo=mailhub5.liv.ac.uk) by mailhub5.liv.ac.uk with esmtp (Exim 4.14) id 19aGBb-0005YF-9n; Wed, 09 Jul 2003 15:44:47 +0100 Received: from pc102199.liv.ac.uk ([138.253.102.199] helo=102198-83472r.liv.ac.uk) by mailhub5.liv.ac.uk with esmtp (Exim 4.14) id 19aGBb-0005YC-7n; Wed, 09 Jul 2003 15:44:47 +0100 Date: Wed, 09 Jul 2003 15:44:48 +0100 From: Steve Morgan To: Van.Snyder@jpl.nasa.gov cc: sc22wg5@dkuug.dk Subject: Re: (SC22WG5.2850) Straw votes to ponder concerning Modules TR Message-ID: <82242000.1057765487@102198-83472r.liv.ac.uk> In-Reply-To: <200307021755.h62HtGgM006819@dkuug.dk> References: <200307021755.h62HtGgM006819@dkuug.dk> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *19aGBb-0001HW-CC*GS.Q7RzxnIc* Sender: owner-sc22wg5@dkuug.dk Precedence: bulk Van, Sorry this is quite late, Steve. --------------------------------------------------------------------- Dr. J. S. Morgan Tel. 0151-794-3746 (3719 for messages) Computing Services Department Fax. 0151-794-3759 The University of Liverpool email. J.S.Morgan @ liv.ac.uk Chadwick Building Peach Street Liverpool L69 7ZF --------------------------------------------------------------------- --On 02 July 2003 10:54 -0700 Van.Snyder@jpl.nasa.gov wrote: > 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? > > -------------------------------------------------------------------------- Having read Lawrie's paper I think it must be submodule association. The bracketing required to override host association when it's not appropriate is confusing and would probably be the source of many errors (when users forget to include it). > > 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? > > -------------------------------------------------------------------------- > I think it should be required. Most people would do it anyway as good practice - wouldn't they? Or is there a 'legacy code' reason why it should be optional? > 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? > > -------------------------------------------------------------------------- > I don't see why this is useful! Isn't defining the same thing twice in the same program unit extreme overkill? I can see why re-defining(confirming) a (forward) interface in a submodule is useful but... > 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? > > -------------------------------------------------------------------------- > Undecided but tending towards 'No' since it would be confusing to have different rules for what would look like two very similar things. > 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? > > -------------------------------------------------------------------------- > I think Lawrie's idea that the FORWARD keyword should prefix the subroutine or function statement is the best choice. I also agree with his use of SEPARATE in the submodule even though it's redundant. > 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. > > ========================================================================== >