From owner-sc22wg5@dkuug.dk Fri Jul 11 11:51:10 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h6B9pAZM066597 for sc22wg5-domo; Fri, 11 Jul 2003 11:51:10 +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 h6B9p5Ec066588 for ; Fri, 11 Jul 2003 11:51:06 +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 h6B9msD06258 for ; Fri, 11 Jul 2003 10:48:54 +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 KAA02226 for ; Fri, 11 Jul 2003 10:59:58 +0100 (BST) Message-ID: <3F0E8A0B.9000707@rl.ac.uk> Date: Fri, 11 Jul 2003 10:57:31 +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 CC: sc22wg5@dkuug.dk Subject: Re: (SC22WG5.2865) Interfaces References: <200307101854.h6AIsF5s062025@dkuug.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-sc22wg5@dkuug.dk Precedence: bulk Van.Snyder@jpl.nasa.gov wrote: > Michael Ingrassia quoted somebody (I don't know who, or the context): Me!! >>>And I think everything needs to be the same, not just the >>>characteristics. >> > > and commented on it: > > >>Let me see if I understand the issue. >> >>INTERFACE >> SUBROUTINE S(I,J) >> END SUBROUTINE S >>END INTERFACE >> >>and >> >>INTERFACE >> SUBROUTINE S(J, I) >> END SUBROUTINE S >>END INTERFACE >> >>are two interface blocks for the same procedure that differ only in >>non-characteristics (the spelling of the dummy argument names). >>A call >> >> CALL S(I=7, J=8) >> >>is consistent with both interface blocks but might well deliver different >>results depending on which of the pair it conforms to. >> >>Is that (part of) your point? Not quite. I am talking about any difference between a separate interface and its implementation. If there is any difference, then we need rules to say which applies in each scope. Yuk! > The subject was "Straw votes to ponder concerning Modules TR." > > The draft of the Modules TR that I wrote does not propose to allow more > than one interface declaration for a module procedure. The procedure > reference will continue to depend on the procedure's one and only > interface declaration, no matter whather that interface is declared by an > interface body or by the procedure body. If the interface is declared > separately from the procedure body, and the procedure body redeclares the > interface, all that the current (1 July) draft requires is that the > characteristics be identical. Not quite. It allows the definition to be pure and the interface not to be (see 20:8-9). Of course, I do not like this either. > A reasonable but separate question is whether we ought to require the > dummy argument names to be the same in the procedure body as in the > interface. > > If we adopt Lawrie's idea that anything in a parent can be redeclared in > a child submodule, there is no problem when the procedure is accessed by > use association, because the definitive interface is the one in the > module. Interfaces in submodules are not accessible by use association. > If we take an additional step and allow anything in the specification > part of a module or submodule, including an interface body, to be > declared more than once, then we almost surely need to require the dummy > argument names to agree. But I think this is a bad idea. > > Suppose we have a tree like this (root at the left, descendants to the > right, brothers vertically arranged): > > M > S1 > S1A > S1B > S2 > > Now suppose that an interface for a procedure P is declared in M, and > again in S1. Suppose there is a body named P in S1A. When P is called > from S1B, is the interface from S1 used, or is the one from M used? > > With submodule association and redeclaration, the pathology Michael > described would be a problem, so we would almost certainly want to > require dummy argument names to agree. > > With host association, the interface for a reference to P from S1B is the > interface in S1, and the body is in S1A. The interface for P that's > accessible by use association is the one in M. If that P is called or > used as a target, there better be a body in S2, because the body in S1A > is not related to the interface in M. It's even worse than I thought. In this example, there may be three interfaces, all different. YUK! Please let's require complete agreement in all interfaces of a separate procedure. We are trying to keep this simple, aren't we? John.