From owner-sc22wg5@dkuug.dk Wed Jun 25 16:02:56 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h5PE2u3c059589 for sc22wg5-domo; Wed, 25 Jun 2003 16:02:56 +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 h5PE2pEc059584 for ; Wed, 25 Jun 2003 16:02:52 +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 19VArG-00048l-1J for sc22wg5@dkuug.dk; Wed, 25 Jun 2003 15:02:46 +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 19VArF-0002AM-Vc for sc22wg5@dkuug.dk; Wed, 25 Jun 2003 15:02:45 +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 19VArF-0002AF-MJ for sc22wg5@dkuug.dk; Wed, 25 Jun 2003 15:02:45 +0100 Date: Wed, 25 Jun 2003 15:02:45 +0100 From: "J.L.Schonfelder" To: sc22wg5@dkuug.dk Subject: Re: (SC22WG5.2800) Thanks to Bill... Message-ID: <3089953.1056553365@jls-rm-home.liv.ac.uk> In-Reply-To: <200306210235.h5L2ZcVH034177@dkuug.dk> References: <200306210235.h5L2ZcVH034177@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/) *19VArG-00048l-1J*eP7/PsZHuXo* Sender: owner-sc22wg5@dkuug.dk Precedence: bulk I am not overly keen on SEPARATE but I could live with it. I entirely agree with its appearing as a prefix on the FUNCTION/SUBROUTINE statement introducing either the interface declaration and the separate module procedure definition. 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. I will reiterate that extending it to cover the relationship between submodules and their parent is creating an anomoly. In all cases todate host association applies between a contained (nested)scoping unit and its containing host. Host association is the association rule that applies widely in block structured languages that have evolved from the Algol stable and in all cases that I know of this nested contained scope feature applies. The redeclaration rule that is also a defining feature of host association is positively undesirable in the case of the disjoint scope of a submodule. So much so that language has to be invented to stop the redeclaration rule applying at least some of the time (in separate procedure definition). I believe host association is out and out wrong and unless significant extra ad hoc restrictions are applied to 03-123 it will remain possible to produce code that will compile but which is very likely to be wrong simply because the association rule is seriously unhelpful. I remain convinced of this and will continue to oppose its use in the TR unless someone can come up with some compelling positive arguments for its use. I would rather have an association rule that was: all parent entities accessible and no redeclaration permitted than the unhelpful redeclaration/masking rule that is implied by host association. A total prohibition on redeclaration could subsequently be relaxed but an inappropriate redeclaration rule cannot later be corrected. --On 20 June 2003 19:35 -0700 Van.Snyder@jpl.nasa.gov wrote: > > Thanks to Bill for actually thinking about the Modules TR before Thursday > of a meeting week. I appreciate the effort he's expended to convince me > of his point of view. Unfortunately (for his camp) I'm not convinced. > > I had almost no correspondence or conversation about the TR between the > time it was approved as a work item and meeting 163. Having little > evidence that anybody else had seriously thought about it before meeting > 163, I believe the current state resulted from hurried decisions. > > The message I got loud and clear after the first draft of the TR was that > it was too complicated. I took that message to heart and made it as > simple as I could. It made me recall Einstein's famous dictum: > > Make it as simple as possible, but no more. > > Given the initial "it's too complicated" message, I don't understand the > "let's make it more complicated" message from meeting 163, and the ones > I'm getting now. > > Let's do it the simplest way possible. We have to distinguish the > interface for a module procedure with separate implementation from an > external interface. If we use host association between a parent and its > child submodules we have to distinguish the procedure's implementation > from an entirely new procedure. We can't do anything simpler than > putting exactly the same mark in the of the subprogram header in > both places. Anything more is unnecessary complexity. A mark other than > a word, say #, would increase rather than decrease life-cycle ownership > costs. Thus: > > Zero words, in either place, are one less than necessary. > For N>1, N words in either place are N-1 more than necessary. > Different words in the two places are one more than is necessary. > Ornamental constructions are more than is necessary. > > If anybody can demonstrate why the simple approach doesn't work, I'll > consider some added complexity. > > If you don't like SEPARATE I urge you to think of a better word, not a > Rube Goldberg scheme to avoid it. > > -- > 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