From owner-sc22wg5@dkuug.dk Wed Jun 18 20:35:51 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h5IIZp06016107 for sc22wg5-domo; Wed, 18 Jun 2003 20:35:51 +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 h5IIZjEc016102 for ; Wed, 18 Jun 2003 20:35:47 +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 h5IIZfJe004889 for ; Wed, 18 Jun 2003 11:35:41 -0700 Received: from math.jpl.nasa.gov (vsnyder@localhost) by math.jpl.nasa.gov (8.12.8/8.12.8/Submit) with ESMTP id h5IIZftN004885 for ; Wed, 18 Jun 2003 11:35:41 -0700 Message-Id: <200306181835.h5IIZftN004885@math.jpl.nasa.gov> X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: inbox To: sc22wg5@dkuug.dk Reply-to: Van.Snyder@jpl.nasa.gov Subject: Re: Modules TR In-Reply-To: Your message of "Wed, 18 Jun 2003 14:42:54 BST." <18183506.1055947374@jls-rm-home.liv.ac.uk> From: Van.Snyder@jpl.nasa.gov Mime-Version: 1.0 Content-Type: text/plain Date: Wed, 18 Jun 2003 11:35:41 -0700 Sender: owner-sc22wg5@dkuug.dk Precedence: bulk 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." 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. 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." 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. 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. -- 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.