From owner-sc22wg5@dkuug.dk Wed Jun 18 11:37:39 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h5I9bdIn013349 for sc22wg5-domo; Wed, 18 Jun 2003 11:37:39 +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 mx1.liv.ac.uk (mx1.liv.ac.uk [138.253.100.179]) by dkuug.dk (8.12.8p1/8.9.2) with ESMTP id h5I9bKEc013337 for ; Wed, 18 Jun 2003 11:37:26 +0200 (CEST) (envelope-from j.l.schonfelder@liverpool.ac.uk) Received: from mailhub5.liv.ac.uk ([138.253.100.157]) by mx1.liv.ac.uk with esmtp (Exim 4.14) id 19SZNT-0002g5-5w for sc22wg5@dkuug.dk; Wed, 18 Jun 2003 10:37:15 +0100 Received: from localhost ([127.0.0.1] helo=mailhub5.liv.ac.uk) by mailhub5.liv.ac.uk with esmtp (Exim 4.14) id 19SZNT-0003w4-2i for sc22wg5@dkuug.dk; Wed, 18 Jun 2003 10:37:15 +0100 Received: from vp135021.liv.ac.uk ([138.253.135.21] helo=jls-rm-home.liv.ac.uk) by mailhub5.liv.ac.uk with esmtp (Exim 4.14) id 19SZNS-0003w0-QR for sc22wg5@dkuug.dk; Wed, 18 Jun 2003 10:37:14 +0100 Date: Wed, 18 Jun 2003 10:37:05 +0100 From: "J.L.Schonfelder" To: sc22wg5@dkuug.dk Subject: Re: (SC22WG5.2772) Modules TR Message-ID: <3443381.1055932624@jls-rm-home.liv.ac.uk> In-Reply-To: <200306180116.h5I1GmdL011630@dkuug.dk> References: <200306180116.h5I1GmdL011630@dkuug.dk> Originator-Info: login-id=jls; server=pop1.liv.ac.uk 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/) *19SZNT-0002g5-5w*VUBb0HzWAsA* Sender: owner-sc22wg5@dkuug.dk Precedence: bulk --On 17 June 2003 18:16 -0700 Van.Snyder@jpl.nasa.gov wrote: > I am a little bit uncomfortable with adding a new form of association, as > Lawrie will propose in an alternative draft of the Modules TR. My > discomfort does not arise so much from a new form per se, but rather from > some trepidation that we may not get it right at first. For example, in > reading Lawrie's draft the umpteenth time, I suddenly realized that his > new "submodule association" can only apply between the scoping units of a > parent and its child submodule. It's clear that a procedure has to > access the scoping unit of its submodule by host association. Otherwise, > it could not access type definitions, variable declarations, or other > procedures within the submodule. This is explicitly stated in my proposal. My point is very much that procedure interfaces which are contained in the scope of the module access the module by host association. The seperate module procedure definitions also access their containing scope, the submodule, by host association. The submodule which is itself a scopeing unit disjoint from the parent module must create an association with the data environment of the parent which ensures that the whole of that environment is accessible unchanged. If host association is assumed between module and submodule (strange when the submodule is not contained in the module) this cannot be guaranteed. Under host association rules data entities declared in the submodule of the same name as those in the module create new entities of these names local to the submodule and they mask those inherited from the module. This is not just undesirable, it will cause serious errors. It will require extra rules for the special case of "host association between submodules and their parent. This makes it not host association so why not define the association specifically as required. Host association also makes it impossible to have checkable confirmatory redeclaration in the submodule. This is essential so as to provide support for the management of true separate development of interface declaration and facility implementation. As a more graphic example of what the effect of trying to use the rules of host association between module an submodule than the one in my previously distributed paper. I believe the rules of host association as they stand and are included in 03-123 would allow the following to compile. MODULE DAD TYPE modstruct REAL::a(10) ENDTYPE modstuct FORWARD INTERFACE FUNCTION modfun(x) type(modstruct)::x REAL::modfun ENDFUNCTION modfun ENDINTERFACE ENDMODULE DAD SUBMODULE (DAD) SON TYPE modstruct ! under host association rules this declaration is permitted CHARACTER::ch ! and it creates a new type called modstruct local to the ENDTYPE modstruct ! submodule and makes the module declared type inaccessible INTEGER:: n IMPLEMENTATION modfun FUNCTION modfun(x) type(modstruct)::x REAL::modfun !........ n= !........ ENDFUNCTION modfun ENDIMPLEMENTATION modfun ENDSUBMODULE SON The question is in the impementation of modfun which type(modstruct) applies. Host association rules would say that the character component one declared in the submodule masks the real component one from the module. However this is clearly not what is required. Therefore we have to introduce a new rule that says that host association from the submodule does not apply within the IMPLEMENTATION block and the module declared version is accessed. But we also wish to access the variable n for some reason internal to the submodule. We have a bizarre situation. Either we apply host association rules as they are and we get a sytactically correct program that is clearly erroneous or we have to invent strange rules as to how host association applies sometimes and not others within submodules. > > In my revised draft, I will assume host association. A new form of > association, which Lawrie calls "submodule association" would be easy to > add. > > -- > 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