From owner-sc22wg5@dkuug.dk Thu Jul 10 20:54:15 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h6AIsF33062014 for sc22wg5-domo; Thu, 10 Jul 2003 20:54: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 h6AIs6Ec062008 for ; Thu, 10 Jul 2003 20:54:10 +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 h6AIs0Jh013527 for ; Thu, 10 Jul 2003 11:54: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 h6AIs0l6013523 for ; Thu, 10 Jul 2003 11:54:00 -0700 Message-Id: <200307101854.h6AIs0l6013523@math.jpl.nasa.gov> X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 X-Exmh-Isig-CompType: comp X-Exmh-Isig-Folder: inbox Reply-to: Van.Snyder@jpl.nasa.gov From: Van.Snyder@jpl.nasa.gov To: sc22wg5@dkuug.dk Subject: Interfaces Mime-Version: 1.0 Content-Type: text/plain Date: Thu, 10 Jul 2003 11:54:00 -0700 Sender: owner-sc22wg5@dkuug.dk Precedence: bulk Michael Ingrassia quoted somebody (I don't know who, or the context): > >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? 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. 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. Suppose the interface for P in S1 isn't declared to be a separate interface. With host association, it would be illegal for a body for P in S1A (or S1B) to claim to be separate from its interface, because the interface accessible to the body by host association wouldn't claim to be its separate interface. With submodule association and redeclaration, I assume this would be caught by requiring agreement on whether the interfaces are for a procedure with a separate body. -- Van Snyder | What fraction of Americans believe Van.Snyder@jpl.nasa.gov | Wrestling is real and NASA is fake? Any alleged opinions are my own and have not been approved or disapproved by JPL, CalTech, NASA, Sean O'Keefe, George Bush, the Pope, or anybody else.