From owner-sc22wg5@dkuug.dk Wed Jun 25 16:19:12 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h5PEJC0C059691 for sc22wg5-domo; Wed, 25 Jun 2003 16:19:12 +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 h5PEJ7Ec059685 for ; Wed, 25 Jun 2003 16:19:08 +0200 (CEST) (envelope-from j.l.schonfelder@liverpool.ac.uk) Received: from mailhub3.liv.ac.uk ([138.253.100.83]) by mx1.liv.ac.uk with esmtp (Exim 4.14) id 19VB70-0001b9-3l for sc22wg5@dkuug.dk; Wed, 25 Jun 2003 15:19:02 +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 19VB70-00034A-1f for sc22wg5@dkuug.dk; Wed, 25 Jun 2003 15:19:02 +0100 Received: from vp135021.liv.ac.uk ([138.253.135.21] helo=jls-rm-home.liv.ac.uk) by mailhub3.liv.ac.uk with esmtp (Exim 4.14) id 19VB6z-000347-PE for sc22wg5@dkuug.dk; Wed, 25 Jun 2003 15:19:01 +0100 Date: Wed, 25 Jun 2003 15:19:01 +0100 From: "J.L.Schonfelder" To: sc22wg5@dkuug.dk Subject: Re: (SC22WG5.2801) Modules TR syntax Message-ID: <4066026.1056554341@jls-rm-home.liv.ac.uk> In-Reply-To: <200306211915.h5LJFofu037968@dkuug.dk> References: <200306211915.h5LJFofu037968@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/) *19VB70-0001b9-3l*7r/16HytJy2* Sender: owner-sc22wg5@dkuug.dk Precedence: bulk --On 21 June 2003 15:15 -0400 Aleksandar Donev wrote: > Hello, > >> I got four not-very-convincing responses. >> > I have to say that your responses have not been very convincing > either..."I like to alphabeticize my procedures" hardly counts as one. > > First, a question for Lawrie, who wants to introduce submodule > association: A separate procedure can be in the same module, in which > case it accesses the module via host association. Do you propose to > change this for such procedures, so that redeclarations of module > entities in the procedure body mean something else? Of course not. The procedure implementation accesses its containing scope by hostassociation as normal. The association I am talking about is the association that applies between a submodule and its parent. The submodule is s disjoint scoping unit in which entities can be declared essentially like any other program unit, or at least like any other module. The key diference is precisely its dependence on its named parent and the association of parent entities into the submodule. A procedure body defined in a submodule will access entities from its containing submodule by host association regardless of whether they were made accessible within the submodule by declaration or by have been inherited from the parent via the relevant parent/child association rule. > > Now, here is a summary of what I consider significantly better syntax > then the current draft, or Lawrie's proposal, but which tries to account > for those proposal's ideas and worries. Of course, all is IMO, and others > can decide the merit of it all. But you are correct in assuming that not > many will think about this before the meeting itself :-( > > MODULE My_Module > > IMPLEMENTATION INTERFACE > ! In this kind of interface host association is automatic > ! IMPORT is not allowed > INTEGER FUNCTION Function_1(x) > INTEGER :: x > END FUNCTION > REAL FUNCTION Function_2(x) > REAL :: x > END FUNCTION > END INTERFACE > > INTERFACE My_Generic > MODULE PROCEDURE :: Function_1, Function_2, Function_3 > ! These are all module procedures > ! We should allow here I believe in 260:27 > CHARACTER FUNCTION Function_4(x) ! External > IMPORT ! OK here > CHARACTER :: x > END FUNCTION > END INTERFACE > > IMPLEMENTS > ! Special association may apply within the IMPLEMENTS block > ! But they better be the same as in the SUBMODULE below! > ! I personally would prefer to keep host association for simplicity... > > IMPLEMENTATION PROCEDURE(Function_2) > ! No redeclaration at all > ! This is my preference, but not necessary > ! I would also agree with requiring full redeclaration > Function_2=x*x > END IMPLEMENTATION > > CONTAINS > > CHARACTER FUNCTION Function_4(x) > CHARACTER :: x > Function_4=x > END FUNCTION > > END MODULE > > SUBMODULE(My_Module) My_Submodule > ! Association rules with My_Module entities is to be determined > ! by Van and Lawrie bout > > IMPLEMENTS > > INTEGER FUNCTION Function_1(x) ! Full-redeclaration > ! Or no redeclaration as above > INTEGER :: x > Function_1=x*x > END FUNCTION > > END SUBMODULE I am sorry but I dislike this syntax for all the reasons that have been setout before. Syntactically I am happy with Van's latest PREFIX in on both interface body and procedure body introductory statemment. > > Notice that I have used the work IMPLEMENT as the root of the two new > keywords, IMPLEMENTATION and IMPLEMENTS. This seems to me the most > natural choice. > > The only blot in this is that for the generic interface My_Generic, one > has to retype the names of the procedures Function_1, Function_2 etc. But > notice that their interface is only declared once, in the IMPLEMENTATION > INTERFACE. I consider this a minor annoyance, and will propose generic > interface merging for the next revision which will fix this and other > annoyances with generic interfaces. > >> I don't want to be sandbagged on this issue, like I was at the Oxford J3 >> meeting concerning a procedure to get error message text given an IOSTAT >> value. >> > My interest and will to contribute to the discussion should in no way be > taken as an attempt to "sandbagg" you. I greatly appreciate your work on > this. The main ideas are great and this is the essence of the proposal. > But I do not like your approach to the syntax, and of course it is my > right to disagree. > > Best, > Aleksandar > -- Lawrie Schonfelder Honorary Senior Fellow University of Liverpool 1 Marine Park, West Kirby, Wirral, UK, CH48 5HN Phone: +44 (151) 625 6986