From owner-sc22wg5@dkuug.dk Thu Jun 19 11:58:17 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h5J9wHmO020022 for sc22wg5-domo; Thu, 19 Jun 2003 11:58:17 +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 h5J9wBEc020016 for ; Thu, 19 Jun 2003 11:58:13 +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 19SwBC-000712-HD for sc22wg5@dkuug.dk; Thu, 19 Jun 2003 10:58:06 +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 19SwBC-0001ez-ET for sc22wg5@dkuug.dk; Thu, 19 Jun 2003 10:58:06 +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 19SwBC-0001ew-Bp for sc22wg5@dkuug.dk; Thu, 19 Jun 2003 10:58:06 +0100 Date: Thu, 19 Jun 2003 10:58:05 +0100 From: "J.L.Schonfelder" To: sc22wg5@dkuug.dk Subject: Re: (SC22WG5.2776) Modules TR Message-ID: <3603411.1056020285@102154-61954c.liv.ac.uk> In-Reply-To: <200306181511.h5IFBGIm014975@dkuug.dk> References: <200306181511.h5IFBGIm014975@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/) *19SwBC-000712-HD*d86EMtoLvBA* Sender: owner-sc22wg5@dkuug.dk Precedence: bulk --On 18 June 2003 11:10 -0400 Aleksandar Donev wrote: > 3. The redeclaration business seems to be the sticky issue. I am somewhat > ambivalent about it. If I had to vote, I would support John's argument: > We *do not* allow redeclation of entities anywhere else, even though > there are places where I would have liked to allow it. But I agree that > Lorrie's example is hidious when interpreted via host association...I > would be happier to forbid redeclaration of anything but the > interface...but do not feel strongly about it yet. Let me give the argument for redeclaration for submodules. It is difficult to give an example here since the issue is one that is very much a feature of large project development. In F95 when a large project is being developed it involves the coding of large complex modules. A considerable part of the development for such modules is the design of the interface to the user. This frequently requires the careful construction of complicated sets of generic procedures. A statement like MODULE PROCEDURE is not very helpful. To properly design a complex generic set you need to think through the full details of the specific procedure interfaces so as to properly ensure the funcionality is right and that the various procedures staisfy the generic resolution rules. This is nontrivial and really requires the writing of the whole interface specification at this point. When producing the first versions of the string module which is on the whole not very big or all that complicated I still found I needed to do this. What I did was write the whole interfaces as comments in the interface blocks. These had then to be repeated in the module procedure definitions several hundred to a thousand lines later in the file. Initially of course I simple did a cut and paste of my commented interface code and made it active. However, very quickly the comments and the actual interfaces got out of step, clearly I was not sufficiently disciplined enough to keep them in step. The forward interface part of the submodule proposal allows the interface definitions to be made active and redeclaration of the interface in the separate module procedure allows these to be kept in step. However, the code of the interface itself is not all that needs to be available and visible to the implementer of the submodule. Unlike in the monolithic module case the submodule is likely to be a separate source code file and in the case of a large project likely to be the responsibility of a separate programmer. When a separate module procedure is implementing facilities for various derived types the structure of those types is an important factor. The interpretation of the components of such types is often dependent on parameters set in the module. This information can of course be given to the implementer in the form of documentation (effectively comments) but now it is likely that the submodule implementer will not have direct ccess to the source code of the parent. I contend that it is desirable in this case that the submodule implementer be given the full redeclaration of the relevant entities with the proviso that these must merly confirm the characteristics of the parent entities to which they refer. This along with the interface code provides full ckeckable documentation for the required implementation. This I believe would provide very significant management support for the correct production of large bodies of code by separate programmers. Dependencies between module and submodule would be explicit and checkable rather than simply being dependent on human "I wrote it consistently with the published documentation". It is this capacity that my proposal for a submodule association provides. > > What I do feel strongly about is the need to either *fully* respecify the > inteface, or not specify it at all, as in: > > SEPARATE PROCEDURE(Name_Of_Procedure) > I would be quite happy with this either /or. I personally would always redeclare everything and would be happy have this as a requirement, i.e. use the above and no redeclaration or use SEPARATE on the FUNCTION or SUBROUTINE statement and redeclare the entire interface. I would still for the above reasons like to be able to redeclare the relevant types and parameters etc. that will be relevant to the correct implemetation of the procedure. -- Lawrie Schonfelder Honorary Senior Fellow University of Liverpool 1 Marine Park, West Kirby, Wirral, UK, CH48 5HN Phone: +44 (151) 625 6986