From owner-sc22wg5@dkuug.dk Wed Jun 25 10:19:29 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h5P8JTnP058067 for sc22wg5-domo; Wed, 25 Jun 2003 10:19:29 +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 h5P8JOEc058062 for ; Wed, 25 Jun 2003 10:19:26 +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 h5P8HPD04639 for ; Wed, 25 Jun 2003 09:17:25 +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 JAA28079 for ; Wed, 25 Jun 2003 09:28:13 +0100 (BST) Message-ID: <3EF95C33.5070103@rl.ac.uk> Date: Wed, 25 Jun 2003 09:24:19 +0100 From: John Reid Reply-To: j.k.reid@rl.ac.uk Organization: Rutherford Appleton Laboratory 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.2810) 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 -------- To: longb@cray.com cc: sc22wg5@dkuug.dk Subject: Re: (SC22WG5.2810) Directions for Modules TR In-Reply-To: Message from Bill Long of "Tue, 24 Jun 2003 18:32:47 CDT." <200306242326.h5ONQ9f7055612@dkuug.dk> Mime-Version: 1.0 Content-Type: text/plain Date: Tue, 24 Jun 2003 17:02:39 -0700 From: Van Snyder Richard wrote: > Did Bill say he saw no point in that? Well, perhaps. I might have > missed it. Anyway, I think it should be allowed...or more pertinently > I don't think it should be disallowed. The main reason is just > that it seems an arbitrary restriction with no particular purpose > or logic. Arbitrary restrictions are a complication and something > for users to memorize and question. Bill wrote: > If we require that 'separate' procedures are defined in submodules, and > not where the interface block is specified, then we still have the old, > simple rule in place 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. > While I'm on the simplification soap box, could we limit the number of > generations to 2? Parents are always modules, and children are always > submodules. Having submodules of submodules seems like an unnecessary > complication. What purpose does it serve? For a large module there may be a need to share entities between procedures in different submodules. With only two levels, the only place to put those shared entities is in the module. This is really part of the implementation. Putting it into the module could cause a compilation/certification cascade as a consequence of changing an implementation detail. So you need at least three levels. Once you have three, there's really no point to a limit, although I doubt in practice we would see more than three. -- Van Snyder | What fraction of Americans believe Van.Snyder@jpl.nasa.gov | Wrestling is real and NASA is fake? Any alleged opinions are my own and have not been approved or disapproved by JPL, CalTech, NASA, Sean O'Keefe, George Bush, the Pope, or anybody else.