From owner-sc22wg5@dkuug.dk Wed Jun 25 21:38:26 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h5PJcQAe061294 for sc22wg5-domo; Wed, 25 Jun 2003 21:38:26 +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 h5PJcKEc061289 for ; Wed, 25 Jun 2003 21:38:22 +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 19VG5v-0007f0-0U for sc22wg5@dkuug.dk; Wed, 25 Jun 2003 20:38: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 19VG5u-0004fb-Uf for sc22wg5@dkuug.dk; Wed, 25 Jun 2003 20:38:14 +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 19VG5u-0004fY-L8 for sc22wg5@dkuug.dk; Wed, 25 Jun 2003 20:38:14 +0100 Date: Wed, 25 Jun 2003 20:38:15 +0100 From: "J.L.Schonfelder" To: sc22wg5@dkuug.dk Subject: Re: Submodule association and host association Message-ID: <23220108.1056573495@jls-rm-home.liv.ac.uk> In-Reply-To: <200306251824.h5PIOb8v028101@math.jpl.nasa.gov> References: <200306251824.h5PIOb8v028101@math.jpl.nasa.gov> 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/) *19VG5v-0007f0-0U*lTvOOC3n4VA* Sender: owner-sc22wg5@dkuug.dk Precedence: bulk I can not see any likelyhood of wanting submodules to be nested within modules since their whole point is their separateness. I agree one should not gratuitously claose off possible enhancements. This is one of the reasons why I am so opposed to host association. Once this is embedded there is no possibility of any change to the redeclaration rules. I have long been infavour of relaxing the redeclaration rules generally since the current prohibition creates irksome constraints but I am not proposing that here. I do want a more general redeclaration rule for submodules so as to support the full separation of submodule and module development but with checkability of attributes, characteristics and definition for inherited entities in the submodule. I am convinced by the work I have done in writing moderate sized modules and in attempting to manage software development teams that a general confirmatorary redeclaration of essential entities within a submodule is highly desirable as an aide to separate devevelopment. Redeclaration creating a new masking entity is a recipe for obfuscation and error. Like John and Van I would like to be able to create submodules by repackaging existing module code with minimal changes. Van's single prefix does this but host association between child and parent makes it all too possible for this to be skrewed by inadvertent virtually uncheckable modification. --On 25 June 2003 11:24 -0700 Van.Snyder@jpl.nasa.gov wrote: > > Lawrie wrote: > >> My only disagreement is with host association as the association rule >> applying between the disjoint scopes of a submodule and its parent. Van >> says he is not convinced by my arguments against host association. I can >> only reply that I am totally unconvinced that there are any arguments >> FOR host association. I have seen no agrument pointing out any >> technical, expressive or functional advantages for using this >> association rule apart from the trivial one that it already exists. > > One possibility that has been suggested is to extend the Submodule idea > to let them be inside of modules instead of just beside them. Modula-2 > always allowed modules within modules. I used this facility occasionally > to partition the resources within a module into those that are available > globally (and of course everywhere within the module) and those that are > shared by a subset of the module's procedures. If Fortran had done this > in 1988 -- and Modula-2 was already ten years old by then, so we had a > model -- we wouldn't have needed accessibility attributes for module > entities (but we would still have needed them for components). Modula as with Pascal, Algol 60, Algol 68 etc. all have host association type rules that apply to all nested blocks. In fact most of these languages do not have the concept of a disjoint scope at all. Every program is logically contained within a logical superblock. This is not the way Fortran has functioned. We do have disjoint scoping units wgere the association rules are different. We do not as yet have non-nested scopes where the rules are as for host association. If we are to introduce such a situation it should be for very good functional reasons. > > Some processors traverse the transitive closure of the USE graph from the > module named on the USE statement to its twigs every time a USE statement > is processed. I've therefore found it useful to move USE statements from > module scope to procedure scope. This can shorten compile times > dramatically. In one case, from more than twenty hours to less than one > minute. It also keeps this information out of the .mod file, which means > that schemes that rely on comparing .mod files to avoid compilation > cascades don't get confused when a USE statement at procedure scope gets > added, deleted or changed. > > BUT, in a module with dozens or hundreds of procedures, it's tedious to > put the same USE statement everywhere, for example to get the kind > parameter for the arithmetic for a class of calculations. > > If the procedures in a module share an entity, it necessarily has to be > declared at module scope. Even if it's private, processors usually put > information about it in the .mod file. Therefore, if it's changed, even > if it has no effect on the "interface" of the module, schemes that compare > .mod files to avoid compilation cascades get confused. > > One could argue "With separate submodules one wouldn't have any need for > contained submodules, so what's the point of allowing them?" I don't > know, but if we ever want to, any choice other than host association > would have almost surely been the wrong one. > > So, as we ponder whether the Modules TR should specify host association or > Lawrie's proposed submodule association relation between a submodule and > its parent, we should keep in mind the effect the choice would have on the > possibilities for future evolution. > > I'm not advocating either position here, just pointing out that we need to > think carefully about our choice. > > -- > 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. > > -- Lawrie Schonfelder Honorary Senior Fellow University of Liverpool 1 Marine Park, West Kirby, Wirral, UK, CH48 5HN Phone: +44 (151) 625 6986