From owner-sc22wg5@dkuug.dk Thu Jun 19 12:32:45 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h5JAWjmX020266 for sc22wg5-domo; Thu, 19 Jun 2003 12:32:45 +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 mx2.liv.ac.uk (mx2.liv.ac.uk [138.253.100.180]) by dkuug.dk (8.12.8p1/8.9.2) with ESMTP id h5JAWeEc020261 for ; Thu, 19 Jun 2003 12:32:41 +0200 (CEST) (envelope-from j.l.schonfelder@liverpool.ac.uk) Received: from mailhub3.liv.ac.uk ([138.253.100.83]) by mx2.liv.ac.uk with esmtp (Exim 4.14) id 19SwiZ-0000gR-HL for sc22wg5@dkuug.dk; Thu, 19 Jun 2003 11:32:35 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mailhub3.liv.ac.uk) by mailhub3.liv.ac.uk with esmtp (Exim 4.14) id 19SwiZ-0003px-Er for sc22wg5@dkuug.dk; Thu, 19 Jun 2003 11:32:35 +0100 Received: from pc102207.liv.ac.uk ([138.253.102.207] helo=102154-61954c.liv.ac.uk) by mailhub3.liv.ac.uk with esmtp (Exim 4.14) id 19SwiZ-0003ps-CX for sc22wg5@dkuug.dk; Thu, 19 Jun 2003 11:32:35 +0100 Date: Thu, 19 Jun 2003 11:32:34 +0100 From: "J.L.Schonfelder" To: sc22wg5@dkuug.dk Subject: Re: (SC22WG5.2781) Modules TR Message-ID: <5672506.1056022354@102154-61954c.liv.ac.uk> In-Reply-To: <200306181835.h5IIZp1Z016118@dkuug.dk> References: <200306181835.h5IIZp1Z016118@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/) *19SwiZ-0000gR-HL*VCBPX/3ia9o* Sender: owner-sc22wg5@dkuug.dk Precedence: bulk --On 18 June 2003 11:35 -0700 Van.Snyder@jpl.nasa.gov wrote: > > Lawrie wrote: > >> By definition any essential data-environment (types,parameters etc.) >> that is declared outside the interface but on which the interface >> depends cannot be redeclared in the submodule under host association >> rules because these create new entities not references to the >> inherited entities. They are not confirmatory declarations, they are >> not checked against the inherited ones, and they cannot provide >> separate checkable documentary source code. > > The fundamental difference between 03-123 and what Lawrie is arguing > about it is that "characteristics shall be identical" is not adequately > satisfied by "the text of the declaration of the characteristics in the > interface body shall be identical to the text of the declaration of the > characteristics in the implementation." No it is not. I am happy with characteristics identical, i am not requiring source code identity but it would be nice to permit it. What I want is more general redeclaration within the submodule scoping unit so as to permit a project manager to provide a stub submodule containing the relevant declarations from the parent to allow a programmer to implement a separate module procedure or a set of them without direct access to the source code of the parent but with effective "documentation" that can be checked for consistency. Host association completely kill this and carries with it all the nasties that I hope I have demonstrated. > > There's more to it: Objects have the same type if they refer to the same > type definition, which is not necessarily true just because the type > names are the same. Objects have the same kind parameter if the value of > the parameter is the same. Objects declared using the same kind > parameter name need not necessarily have the same kind parameter value. > > Lawrie's assertion that different characteristics in an interface > declaration and body definition could not be checked and diagnosed is not > correct. That is not my assertion at all. Of course they should be checked. My examples were to show what bizarre code was possible and where redclaration of the interface or not could make a significant and to my mind unacceptable difference to the interpretation. > > Other things could go wrong, but not things related to characteristics. > For example: > > module PARENT > integer, parameter :: N = 10 > forward interface > subroutine S ( X ) > real :: X(N) > end subroutine S > end interface > end module PARENT > > submodule(parent) CHILD > integer, parameter :: N = 50 > contains > subroutine S ( X ) > real :: X(N) > .... > end subroutine S > end module PARENT > > is allowed, and would not be caught, because the extent of an > explicit-shape dummy argument is not a characteristic. This is another > example of "here's a sharp knife; be careful not to shoot yourself in > the foot." > But why create the knife when it only does part of the job when what is needed is a spoon. > Some might prefer checkable repetition of declarations of entities from > the parent module in the submodule. It's also possible that host > association is exactly what others want. Suppose a module has some > entity E that is shared among several module procedures, but E does not > affect the forward interface declaration for procedure P. Now suppose P > is defined in a submodule, and in that submodule there are several > procedures Q, R, .... that share an entity named E that they desire to be > entirely independent from the E declared in the parent. One can argue > that this ought to be prohibited, or argue that it ought to be allowed. > Both arguments have merit. Neither one illustrates that the other > approach is unworkable or undesirable. This was an argument that was given when host association was proposed for USE. It was at that time, rightly in my opinion, felt that such a rule was not desirable for association between disjoint scopes such as a module and a USEing program unit. In this case the redeclaration rule was not permitted. In the context of all the accessibility controls and the renaming this was probably correct. In the context of the disjoint scopes of module and submodule where total accessibility of the parent is required I believe redeclaration to confirm characteristics and properties is the right rule. > > Lawrie is correct in assuming that the intent in 03-123 was to allow to > put a forward interface in the scoping unit either of a module or > submodule, and to have the corresponding implementation be in the same > program unit as the interface, or in a descendant. If the words in > 03-123 don't say that, it's a mistake that ought to be corrected. > I think John is wrong here. A submodule may need to have a number auxilliary procedures that are needed to implement the facilities it is handling. These may best be delegated to a sub-submodule so as to further limit the cascade compilation effect. An artificial restriction of forward interfaces to the ultimate parent module would be unhelpful and is unnecessary. There is a mistake in 03-123 in this. > -- > 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. -- Lawrie Schonfelder Honorary Senior Fellow University of Liverpool 1 Marine Park, West Kirby, Wirral, UK, CH48 5HN Phone: +44 (151) 625 6986