From owner-sc22wg5@dkuug.dk Wed Jun 18 15:56:58 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h5IDuw6B014535 for sc22wg5-domo; Wed, 18 Jun 2003 15:56:58 +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 h5IDuqEc014530 for ; Wed, 18 Jun 2003 15:56:54 +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 19SdQc-0002qK-Vk for sc22wg5@dkuug.dk; Wed, 18 Jun 2003 14:56:46 +0100 Received: from localhost ([127.0.0.1] helo=mailhub5.liv.ac.uk) by mailhub5.liv.ac.uk with esmtp (Exim 4.14) id 19SdQc-0005WV-Tg for sc22wg5@dkuug.dk; Wed, 18 Jun 2003 14:56:46 +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 19SdQc-0005WR-Mk for sc22wg5@dkuug.dk; Wed, 18 Jun 2003 14:56:46 +0100 Date: Wed, 18 Jun 2003 14:56:47 +0100 From: "J.L.Schonfelder" To: sc22wg5@dkuug.dk Subject: Re: (SC22WG5.2774) Modules TR Message-ID: <19016354.1055948207@jls-rm-home.liv.ac.uk> In-Reply-To: <200306181326.h5IDQSCT014319@dkuug.dk> References: <200306181326.h5IDQSCT014319@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/) *19SdQc-0002qK-Vk*iqyrUebQQFU* Sender: owner-sc22wg5@dkuug.dk Precedence: bulk --On 18 June 2003 14:30 +0100 John Reid wrote: > WG5, >> >> 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 > > No. It is excluded by lines 16-19 of page 9 of J3/03-123. I do not think these cover the case at all. The redeclaration of the interface above is identical to that in the module. It has an undesirable different effect because of a previous declaration that should have been illegal. Consider a modified version of the submodule. 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() ! minimal redeclaration of the interface characteristics ! inherited from the parent module type(modstruct):: wk ! a local variable declaration presumably employing the character ! version of the type !........ n= !........ ENDFUNCTION modfun ENDIMPLEMENTATION modfun ENDSUBMODULE SON We now have the bizarre situation that the dummy variable x resulting from the module interface declaration of type modstruct is of a different type from the local variable wk declared to be of type modstruct. The declaration of the new meaning for type(modstruct) is the declaration that should be illegal which under host association rules it is not. > > But this example does illustrate a feature that Lawrie wants: to be able > to redeclare parent entities as an aid to documentation and maintenance. > It might be argued that we are being inconsistent in allowing such > redeclaration for the procedure interface but not for other things, but > we already have redeclaration for interfaces in Fortran 95. We do not > have redeclaration of entities accessed from a module; J3/03-123 is being > consistent with this. > > Cheers, > > John. > -- Lawrie Schonfelder Honorary Senior Fellow University of Liverpool 1 Marine Park, West Kirby, Wirral, UK, CH48 5HN Phone: +44 (151) 625 6986