From owner-sc22wg5@dkuug.dk Thu Jun 26 11:00:35 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h5Q90Zu1065505 for sc22wg5-domo; Thu, 26 Jun 2003 11:00:35 +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 inf.rl.ac.uk (nfs7.inf.rl.ac.uk [130.246.72.7]) by dkuug.dk (8.12.8p1/8.9.2) with ESMTP id h5Q90VEc065500 for ; Thu, 26 Jun 2003 11:00:32 +0200 (CEST) (envelope-from j.k.reid@rl.ac.uk) Received: from numerical.cc.rl.ac.uk (numerical [130.246.8.23]) by inf.rl.ac.uk (8.11.6+Sun/8.8.8) with ESMTP id h5Q8wWD07229 for ; Thu, 26 Jun 2003 09:58:32 +0100 (BST) Received: from rl.ac.uk (jkr.cse.rl.ac.uk [130.246.9.202]) by numerical.cc.rl.ac.uk (8.8.8+Sun/8.8.8) with ESMTP id KAA28221 for ; Thu, 26 Jun 2003 10:09:20 +0100 (BST) Message-ID: <3EFAB75C.2050600@rl.ac.uk> Date: Thu, 26 Jun 2003 10:05:32 +0100 From: John Reid Reply-To: j.k.reid@rl.ac.uk User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: WG5 Subject: Re: (SC22WG5.2811) Directions for Modules TR] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-sc22wg5@dkuug.dk Precedence: bulk -------- 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" 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)