From owner-sc22wg5@dkuug.dk Fri Jun 20 13:26:30 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h5KBQUE7027581 for sc22wg5-domo; Fri, 20 Jun 2003 13:26:30 +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 h5KBQLEc027576 for ; Fri, 20 Jun 2003 13:26:26 +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 19TK23-0004eK-Qw for sc22wg5@dkuug.dk; Fri, 20 Jun 2003 12:26:15 +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 19TK23-00012G-Oc for sc22wg5@dkuug.dk; Fri, 20 Jun 2003 12:26:15 +0100 Received: from vp135020.liv.ac.uk ([138.253.135.20] helo=jls-rm-home.liv.ac.uk) by mailhub3.liv.ac.uk with esmtp (Exim 4.14) id 19TK23-00012D-Fq for sc22wg5@dkuug.dk; Fri, 20 Jun 2003 12:26:15 +0100 Date: Fri, 20 Jun 2003 12:26:13 +0100 From: "J.L.Schonfelder" To: sc22wg5@dkuug.dk Subject: Re: (SC22WG5.2787) Modules TR Message-ID: <2691089.1056111973@jls-rm-home.liv.ac.uk> In-Reply-To: <200306191806.h5JI6COe022489@dkuug.dk> References: <200306191806.h5JI6COe022489@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/) *19TK23-0004eK-Qw*7AhGiZzpEUE* Sender: owner-sc22wg5@dkuug.dk Precedence: bulk --On 19 June 2003 14:05 -0400 Aleksandar Donev wrote: > J.L.Schonfelder wrote: > > "Let me give the argument for redeclaration for submodules." > I am not arguing against redeclaration, I was merely thinking about > consistency. There are other places where I would like to allow it. For > example, I would want to specify the interface of all type-bound > procedures in an ABSTRACT interface block, very close to where the type > is declared, even if they are not deferred bindings. Right now we have: > > TYPE ... > CONTAINS > PROCEDURE :: binding=>some_proc ! Go find this proc to see its interface > ENDTYPE > > so that it is not easy to first design the interface (which as you say is > a hard organizational step), and then write the implementations. The > submodule proposal can help with the example above because some_proc can > be made to be a procedure whose interface is a FORWARD one, and then the > implementation can be elsewhere. I agree with Aleksandar. I would go further. The prohibition on redeclaration that has been a part of Fortran theology for decades has never to my mind had much real justification. The most common argument was that declaring something twice must be an error so it should be banned. Designing this ban into the language has frequently been a tricky part of the wording of the standard. As has been clear now for a long time there are a growing number of features where it would be positively helpful to allow redeclaration as long as it confirmed the attributes and characteristics of the named entity. If I had my "druthers" I would allow redeclaration everywhere subject to the above rule but I am not proposing such a drastic change at this point. However, submodules are a new program unit being introduced specifically to aid the development of large complex codes. Redeclaration restricted to the submodule does not violate the prohibitions elsewhere in the language and it positively helps the development process as well as making horrible code possibilities less available. If the theology prevails I would still argue against host association as the relation between the submodule and its parent. I would prefer the association to be: - all parent entities accessible and no redeclaration allowed, This would be cleaner and less error prone than host association but also much less helpful than the redeclaration rule I am advocating. > > I did not hear any replies to my comment #2: > > Aleksandar Donev wrote: > >> the SEPARATE is not really a characteristic of the procedure (this is >> still a procedure that is compiled and called like any other (comapre >> this to PURE/ELEMENTAL, etc, which apply to the way the procedure is >> called and used), but rather, SEPARATE applies to the relation between >> this procedure and its host. Thus, like we have CONTAINS, it seemed >> natural to have an equivalent construct which marks a piece of the >> subroutines as being implementations. I personally would prefer: >> >> SUBMODULE(Parent_Module) :: Sub_Module >> ... >> IMPLEMENTS >> ! Separate procedures >> CONTAINS >> ! Regular ones >> END SUBMODULE >> I could live with this but I would still want to add the qualifier for the interface to the interface body and not the interface block. >> or some variant thereof. > > After thinking more about this and Richard's comments about adding things > to the FUNCTION/SUBROUTINE statement, I am more convinced that putting > SEPARATE there is a bad idea. Just like we do not say MODULE FUNCTION or > MODULE SUBROUTINE for module procedures, we should not say SEPARATE. I do not accept Richard's comment. Adding the qualifier to the interface block does not improve things and it adds complications. Adding a prefix to the function/subroutine statement in a very well constrained context does not appear to me to carry any particular problems. > > And kudos to NAG for catching the mismatch in dummy argument shapes. But, > what if the dummy of the FORWARD interface had: > > REAL, DIMENSION(n*n) :: a ! Here n=5 The exact dependence on the named entities in the specification expressions involved in declaring dummy arguments etc. are characteristics of the procedure as I read the standard so the accidental equivalence in value of n*n and m would not make the characteristics identical. > > and the one in the implementation had dimension m, where m=25, or maybe > even n, where n was redeclared to be 25? This will work, yet it is > clearly a mess we do not want to introduce. As Lawrie said, don't make a > knife when all we need is a spoon. > > Best, > Aleksandar > > -- Lawrie Schonfelder Honorary Senior Fellow University of Liverpool 1 Marine Park, West Kirby, Wirral, UK, CH48 5HN Phone: +44 (151) 625 6986