From owner-sc22wg5@dkuug.dk Thu Jun 26 13:02:55 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h5QB2t3H066125 for sc22wg5-domo; Thu, 26 Jun 2003 13:02:55 +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 h5QB2nEc066120 for ; Thu, 26 Jun 2003 13:02:51 +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 19VUWa-0003S5-67 for sc22wg5@dkuug.dk; Thu, 26 Jun 2003 12:02:44 +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 19VUWa-0006sF-4D for sc22wg5@dkuug.dk; Thu, 26 Jun 2003 12:02:44 +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 19VUWZ-0006sA-Ss for sc22wg5@dkuug.dk; Thu, 26 Jun 2003 12:02:43 +0100 Date: Thu, 26 Jun 2003 12:02:42 +0100 From: "J.L.Schonfelder" To: WG5 Subject: Re: (SC22WG5.2830) Directions for Modules TR] Message-ID: <2039472.1056628961@jls-rm-home.liv.ac.uk> In-Reply-To: <200306260908.h5Q98BT8065563@dkuug.dk> References: <200306260908.h5Q98BT8065563@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/) *19VUWa-0003S5-67*lzYCnyq64Z.* Sender: owner-sc22wg5@dkuug.dk Precedence: bulk --On 26 June 2003 10:05 +0100 John Reid wrote: > > > -------- Original Message -------- > Subject: Re: (SC22WG5.2811) Directions for Modules TR > Date: Wed, 25 Jun 2003 15:14:57 +0100 (BST) > From: Malcolm Cohen > To: sc22wg5@dkuug.dk > CC: John Reid > > Someone wrote: > >The old rules would remain in place for procedures that aren't announced > >to be separate from their interfaces. We don't want to break any > >compatibility with Fortran 95 in this respect. Separate procedures are > >new entities. We can choose whatever rules we want for them. They're > >enough different that the rules for other entities don't necessarily > make >the most sense. For procedures that have separate interfaces, it > seems >to me that a rule that says "anywhere" instead of "anywhere > except in the >same program unit" is simpler. > > This does not make a lot of sense to me. > Perhaps I've misunderstood what is being proposed. > > The proposal (if I understand correctly) is that > "SEPARATE MODULE PROCEDURE smp" You have missunderstood the proposal, both mine and Van's. We are advocating that the SEPARATE/FORWARD prefix be added to the FUNCTION or SUBROUTINE statement that introduces the interface body. This is to indicate that the procedure whose interface this is is not an external procedure but a separate module procedure whose implementation body will appear contained in a descendant module/submodule of the current program unit, and that this interface inherits the data environment of its current containing host by host association in contradistintion to the situation when the prefix does not occur when the interface does not inherit the interface. IMPORT is not adequate. It would be a pain to have to add it to every interface charateristic that needed to inherit from its host in this context since it will usually apply to most of them and it does not indicate that this interface is not that of an external which is also needed. A separate module procedure interface declaration must be distinguished from an external procedure interface declaration and The addition of a distinguishing prefix is the simplest and most convenient way of doing this, IMO. > means that "smp" might be separate, and might not, whereas > "MODULE PROCEDURE mp" > continues to mean that "mp" cannot be separate. > > If so, I don't understand why we have a keyword in the first place. > Surely all this means is that everyone will put "SEPARATE" in front of > every MODULE PROCEDURE statement, so that it doesn't matter where they > define it. Would it not be less complicated just to make MODULE PROCEDURE > work that way always? > > And with my error detecting hat on, having SEPARATE mean "somewhere else" > rather than "anywhere" means that one can diagnose the forgotten routine > at compile time rather than link time (when people start putting SEPARATE > on everything I mean). [Actually, with this hat on, it would be nice to > have more indication of where to start looking; naming the submodule in > which to start looking would be an advantage here, even if - as one would > want - that submodule could further defer the implementation.] > > And with my language semantics hat on, SEPARATE really means "somewhere > else" more than it means "anywhere". Can't we change the keyword name to > something more meaningful like "ANYWHERE" or "YOU_WILL_HAVE_TO_LOOK_& > &HERE_AS_WELL_AS_ELSEWHERE_TO_FIND_THIS_ONE" or "ERRORPRONE" instead? > > Cheers, > -- > ...........................Malcolm Cohen, NAG Ltd., Oxford, U.K. > (malcolm@nag.co.uk) > > -- Lawrie Schonfelder Honorary Senior Fellow University of Liverpool 1 Marine Park, West Kirby, Wirral, UK, CH48 5HN Phone: +44 (151) 625 6986