From owner-sc22wg5@dkuug.dk Thu Jul 10 19:40:09 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h6AHe98s061488 for sc22wg5-domo; Thu, 10 Jul 2003 19:40:09 +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 inf.rl.ac.uk (nfs7.inf.rl.ac.uk [130.246.72.7]) by dkuug.dk (8.12.8p1/8.9.2) with ESMTP id h6AHe3Ec061483 for ; Thu, 10 Jul 2003 19:40:05 +0200 (CEST) (envelope-from j.k.reid@rl.ac.uk) Received: from numerical.cc.rl.ac.uk (numerical [130.246.8.23]) by inf.rl.ac.uk (8.11.6+Sun/8.8.8) with ESMTP id h6AHbqD04804 for ; Thu, 10 Jul 2003 18:37:52 +0100 (BST) Received: from rl.ac.uk (jkr.cse.rl.ac.uk [130.246.9.202]) by numerical.cc.rl.ac.uk (8.8.8+Sun/8.8.8) with ESMTP id SAA02133 for ; Thu, 10 Jul 2003 18:48:55 +0100 (BST) Message-ID: <3F0DA671.8080003@rl.ac.uk> Date: Thu, 10 Jul 2003 18:46:25 +0100 From: John Reid Reply-To: j.k.reid@rl.ac.uk User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: WG5 Subject: Re: (SC22WG5.2850) Straw votes to ponder concerning Modules TR References: <200307021755.h62HtGgM006819@dkuug.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-sc22wg5@dkuug.dk Precedence: bulk > ========================================================================== > > 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. I can see merit in both alternatives, but am tending towards "host association" since there are so many places in the standard where the words 'use or host association' are used. I do not feel comfortable with changing all these to 'use, submodule, or host association'. > ========================================================================== > > 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). I would prefer to require redeclaration. I hate the idea of partial redeclaration - see, for example, page 4 of 03-123, where the argument list is omitted, which makes the dummy arguments look like local variables. And I think everything needs to be the same, not just the characteristics. If it is not, which interface applies in the scope of the submodule? > ========================================================================== > > 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. Agreed. > ========================================================================== > > Should the interface body for a module procedure that has a separate body > automatically access its environment by host association? Yes. These are module procedures, so they access their host by host association. > ========================================================================== > > What syntax should be used to indicate that a module procedure has a > separate interface body? I like what Van has now: the same keyword in the interface and the implementation to say that this is a separate module procedure. > > ========================================================================== > > I believe an additional question is reasonable for a straw vote: > > Should a submodule be allowed as a parent of another submodule? > >------------------------------------------------------------------------------- Well, not allowing this would certainly simplify the proposal, but Van points out that it would lead to a significant loss of functionality: the substructuring of huge programs. If we restrict the number of levels to 3, we could avoid the terms 'ancestor' and 'descendant' by adding 'grandparent' and 'grandchild', but I am opposed since it means we have to say 'parent or grandparent' instead of 'ancestor' and 'child or grandchild' instead of 'descendant'. We could restrict the number of levels to 3 and add a note to say that an ancestor is a child or grandchild and a descendant is a child or grandchild - would perhaps help the reader (and the implementor) - but I prefer not. Cheers, John.