From owner-sc22wg5@dkuug.dk Sun Jul 13 00:32:28 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h6CMWSfF078102 for sc22wg5-domo; Sun, 13 Jul 2003 00:32:28 +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 mail1.cray.com (mail1.cray.com [136.162.0.111]) by dkuug.dk (8.12.8p1/8.9.2) with ESMTP id h6CMTKEc078075 for ; Sun, 13 Jul 2003 00:32:23 +0200 (CEST) (envelope-from longb@cray.com) Received: from relayb.mw.cray.com (relayb.us.cray.com [192.168.252.110]) by mail1.cray.com (8.12.9/8.12.9/gw-1.2) with ESMTP id h6CMTC4G029997; Sat, 12 Jul 2003 17:29:13 -0500 (CDT) Received: from saffron.us.cray.com (saffron.mw.cray.com [172.31.27.14]) by relayb.mw.cray.com (8.12.9/8.12.6/hub-1.2) with ESMTP id h6CMTAbM004059; Sat, 12 Jul 2003 17:29:10 -0500 (CDT) Received: from cray.com (cf-vpn-192-168-239-23 [192.168.239.23]) by saffron.us.cray.com (8.8.8/Cray-server-1.6-nhsmod011017) with ESMTP id RAA614507; Sat, 12 Jul 2003 17:29:06 -0500 (CDT) Message-ID: <3F108D61.8070807@cray.com> Date: Sat, 12 Jul 2003 17:36:17 -0500 From: Bill Long Reply-To: longb@cray.com Organization: Cray Inc. User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Van.Snyder@jpl.nasa.gov CC: sc22wg5@dkuug.dk Subject: Re: (SC22WG5.2872) Consequences of current design of Modules TR References: <200307112222.h6BMMQTb069726@dkuug.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Cray-VirusStatus: clean Sender: owner-sc22wg5@dkuug.dk Precedence: bulk I would just point out that all of this complexity is avoided it we disallow grandchildren. Cheers, Bill Van.Snyder@jpl.nasa.gov wrote: >The current draft of the Modules TR specifies that a submodule accesses >its parent module or submodule by host association. There are some >"interesting" consequences of this. These are all obvious once you >think them through, but I want you to be aware of them before you try >to choose whether a child submodule ought to access its parent by host >association or the new form that Lawrie proposes. > >Suppose you have a module M with a child submodule C and a grandchild G. > >Suppose in M you declare a separate interface for a module procedure P. >Suppose in C you declare another separate interface for a module procedure P. >Suppose in G you define a separate module procedure P. > >The procedure P in G is related to the interface in C, not the one in M. >This is the way host association works, and the TR does not propose to >change it. If another module accesses the interface for P from M, it >can't invoke P or use it for a target or actual argument, because there's >no corresponding procedure. Hopefully, your linker will gripe. Remember, >the name for P that the linker sees is almost surely not P (or p or p_). >It should be mangled with C (not M!) because that's where it's interface >is declared. But C is not accessible by use association. Any scoping >unit that does "use M, only: P" is going to get a P mangled with M. > >Now suppose M has another child submodule C2, and you define a separate >module procedure P there. Then that P's name would be mangled with >M (not C2!), and "use M, only P" would access that P. > >Now suppose C has another submodule G2, in which there is a reference to P. >This refers to the P mangled with C, which body is in G, not the P mangled >with M, which body is in C2. > >This may be exactly what you want to happen, but you need to be aware of it, >and use it carefully. It's no different from an internal procedure having >an interface body for a dummy procedure that's the same name as an interface >body for an external procedure declared in its host procedure. > >Start over. > >Suppose in M you declare a separate interface for a module procedure P. >Suppose in C you declare an interface for an external procedure, also named P. >Suppose in G you define a separate module procedure P. > >The definition of P in G is illegal. It cannot access a separate interface >declaration of the same name by host association. The interface of the same >name that it accesses by host association is not a separate interface. > >This is the way host association works. We all know how host association >works. None of this should be a surprise, once you think it through. > >If we adopt Lawrie's proposal for a new kind of association, and allow to >redeclare anything that's accessed from a parent by that kind of association, >we should require procedure interfaces to have identical characteristics >and identical dummy argument names. Otherwise, you could get the kind of >strangeness noticed by Michael Ingrassia yesterday (or was it Wednesday?). > > > -- Bill Long longb@cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120