From owner-sc22wg5@dkuug.dk Sun Jul 6 11:09:29 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h6699Tne031063 for sc22wg5-domo; Sun, 6 Jul 2003 11:09:29 +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 h6699JEc031058 for ; Sun, 6 Jul 2003 11:09:24 +0200 (CEST) (envelope-from j.l.schonfelder@liverpool.ac.uk) Received: from mailhub5.liv.ac.uk ([138.253.100.157]) by mx1.liv.ac.uk with esmtp (Exim 4.14) id 19Z5W8-000089-9A; Sun, 06 Jul 2003 10:09:08 +0100 Received: from localhost ([127.0.0.1] helo=mailhub5.liv.ac.uk) by mailhub5.liv.ac.uk with esmtp (Exim 4.14) id 19Z5W8-00085g-6w; Sun, 06 Jul 2003 10:09:08 +0100 Received: from vp135021.liv.ac.uk ([138.253.135.21] helo=jls-rm-home.liv.ac.uk) by mailhub5.liv.ac.uk with esmtp (Exim 4.14) id 19Z5W7-00085d-S2; Sun, 06 Jul 2003 10:09:07 +0100 Date: Sun, 06 Jul 2003 10:09:07 +0100 From: "J.L.Schonfelder" To: Van.Snyder@jpl.nasa.gov, sc22wg5@dkuug.dk Subject: Re: (SC22WG5.2850) Straw votes to ponder concerning Modules TR Message-ID: <3187022.1057486147@jls-rm-home.liv.ac.uk> In-Reply-To: <200307021755.h62HtGgM006819@dkuug.dk> References: <200307021755.h62HtGgM006819@dkuug.dk> Originator-Info: login-id=jls; server=pop1.liv.ac.uk 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/) *19Z5W8-000089-9A*ZV.BdJOQJIg* Sender: owner-sc22wg5@dkuug.dk Precedence: bulk Here are my votes on Van's questions! --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? > > -------------------------------------------------------------------------- > > 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. Clearly I feel strongly that host association is a bad idea. I believe that submodules are different from other program units and hence a different relationship is justified and is functionally desirable. > > ========================================================================== > > Should it be optional, prohibited or required to redeclare the > characteristics of a module procedure that has separate interface in its > body? > I believe an optional but blanket redeclaration rule is desirable. This is what is made technically possible and straight forward by submodule association. Host association makes it necessary that redeclaration is restricted to the separate procedures introducing a special case. Since I profoundly dislike this special case structure caused by the use of host association I would probably vote against the TR as a whole in that form my vote here would be somewhat moot. However, I would prefer redeclaration to be required if I had to make a choice. > -------------------------------------------------------------------------- > > 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? An emphatic yes! To prohibit it is applying a gratuitous restriction that to my mind serves no useful purpose. > > -------------------------------------------------------------------------- > > 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? Yes. > > -------------------------------------------------------------------------- > > 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? Prefix on FUNCTION/SUBROUTINE statement in both interface body and separate procedure definition. > > -------------------------------------------------------------------------- > > 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. > > ========================================================================== > -- Lawrie Schonfelder Honorary Senior Fellow University of Liverpool 1 Marine Park, West Kirby, Wirral, UK, CH48 5HN Phone: +44 (151) 625 6986