From owner-sc22wg5@dkuug.dk Tue Sep 16 17:25:08 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h8GFP8E7067618 for sc22wg5-domo; Tue, 16 Sep 2003 17:25:08 +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 h8GFP2Cp067608 for ; Tue, 16 Sep 2003 17:25:04 +0200 (CEST) (envelope-from j.l.schonfelder@liverpool.ac.uk) Received: from mailhub5.liv.ac.uk ([138.253.100.157]) by mx1.liv.ac.uk with esmtp (Exim 4.14) id 19zHhW-00071l-B7 for sc22wg5@dkuug.dk; Tue, 16 Sep 2003 16:25:10 +0100 Received: from localhost ([127.0.0.1] helo=mailhub5.liv.ac.uk) by mailhub5.liv.ac.uk with esmtp (Exim 4.22) id 19zHhW-0000c4-99 for sc22wg5@dkuug.dk; Tue, 16 Sep 2003 16:25:10 +0100 Received: from vp135020.liv.ac.uk ([138.253.135.20] helo=jls-rm-home.liv.ac.uk) by mailhub5.liv.ac.uk with esmtp (Exim 4.14) id 19zHhV-0000bq-TU for sc22wg5@dkuug.dk; Tue, 16 Sep 2003 16:25:09 +0100 Date: Tue, 16 Sep 2003 16:25:06 +0100 From: "J.L.Schonfelder" To: WG5 Subject: Re: (SC22WG5.2996) New papers Message-ID: <9014772.1063729506@jls-rm-home.liv.ac.uk> In-Reply-To: <200309121417.h8CEHeFH033831@dkuug.dk> References: <200309121417.h8CEHeFH033831@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/) *19zHhW-00071l-B7*RR0fkOu2YB.* Sender: owner-sc22wg5@dkuug.dk Precedence: bulk The following is my comments on N1576 the changes proposed by J3 to the technical content agreed at Dresden of the Modules TR. After due consideration I believe none of these changes should be made. --------------------------------------------------------------------------- --- ISO/IEC JTC1/SC22/WG5/N15?? 16-Sep-2003 To: WG5 From: Lawrie Schonfelder Subject: Comments on changes to TR 19767 proposed by J3 at meeting 165 Reference: N1576 I believe all these proposed changes to be unnecessary and undesirable. 1. Management of the submodule name. As defined at Dresden the only contexts in which a submodule name could appear referring to a submodule were the header and END statements of the submodule itself and as the parent name in the header of one of the submodule's immediate children. There is therefore no possible name clash with any local entity in any program unit, even in itself or its descendants or ancestors. To create a problem by defining a submodule name as local to its ultimate ancestor is unfriendly in the extreme. Such a useless definition makes a name currently unknown, essentially irrelevant, and undeclarable nevertheless part of the class 1 local name space of the module, a name space that is likely in any large project to be already cluttered. It is claimed in N1576 that this is proposed to solve a potential name management problem because of conflicts in the global name space, which by assumption the submodule name inhabits. It is not clear to me that a submodule name is global in the sense that an external procedure name is global. A submodule name must be global in the same sense as a module name must be global if it is used. That is the processor must be able to locate the submodule if it is referenced as a parent and a submodule's contents must be accessible if any of its separate procedures are invoked. If a submodule has no descendants, its name plays no logical part in the program. It may of course be employed by the processor to help assemble the program. The operating system may be told to link code from one named submodule rather than another to form the executable program. To this extent the submodule name is clearly global not local. To have two submodules of the same name with the same ancestor could be a source of problems and probably should be disallowed. However, two submodules of the same name but with different module ancestors are also likely to be a problem if only for the system. It would be simpler and less likely to cause problems if the space of names of modules and submodules prohibited duplicates. The TR is rightly aimed at supporting large project development and as such there might be a large number of submodules involved. There will therefore be a significant name management problem but this will be most likely many times easier than the name management problems with local names. A project with a few hundred submodules will probably involve many thousands of local data entity and procedure names. Also as pointed out above there is no need for the language to define submodule names as being part of the same name space as external procedures (or even modules). I believe the global name management problem for submodule names to be minor and to attempt to solve this non-problem by defining such names to be local to their anscestor module as a bad idea. The proposed syntax requiring that both the immediate parent and the ultimate module ancestor be named on the submodule header statement is both unnecessary and undesirable. The processor must be able to identify the ancestor module since it cannot compile the submodule without accessing information from the whole ancestor branch. To require the user to specify the module when the processor must know this anyway is only creating another chore for the user and another possible source of error. Neither of these proposed changes to the Dresden proposals should be made. 2. Requiring a submodule to be a child of a module but allowing submodules to USE one another. The motivation for this change is far from apparent. Nor is it clear that there is any significant benefit from the change. The Dresden proposal was simple in that the structural relationship between a module and its collection of submodules was one of a tree with no same-level cross-links. In principle, every entity declared at a given node of the tree was visible and accessible in all its descendants. In the discussion at Dresden it was clear that it was easy to see examples where three levels would be required, viz. a module defining the accessible user interface, a child submodule that defined "hidden" common data and auxiliary procedure interfaces, and grand children submodules that defined the actual implementations. No obvious example came to light where great grand children would be essential but since it was considered just as easy to specify the general case as to apply an arbitrary cut of at 3 levels, this was how the TR was defined. It was also argued that the general case was just as easy if not easier to implement than an arbitrarily restricted version. I for one would be very strongly opposed to now imposing an arbitrary restriction, particularly to one that requires only one level as this proposal appears to do. I do not see how allowing one submodule to use another submodule is an improvement. Clearly if submodules are limited to being children only, then getting access to hidden common data etc from one submodule into another would require something like this. However, the combination takes a simple regular structure and creates a mess. We would now have host association applying down the admittedly rather shallow tree but use association applying across it. This is an unwanted complication. I for one am puzzled as to how this could be employed as effectively as the original multi-level tree. For example, if I declared the interface for a hidden auxiliary module procedure in one submodule could I define its separate procedure implementation in another that USEd the first submodule? Assuming this is legal, and I cannot see why it should not be except that it might be forbidden by dictat, how would I access this procedure in a third submodule, by USE on the first declaring submodule or USE on the second implementing submodule? Perhaps both would be allowed, they probably should be, but how do the two relationships differ? Presumably, if the procedure is accessed in a third submodule by USE on the implementing submodule, a change in the second submodule would trigger a recompilation but not if the USE was on the first. In fact, exactly how are the recompilation effects now managed? In the tree, this was clear. Recompilation, is triggered down the tree but not up. We now have a more complicated set of possibilities. This, in my opinion, is an ill thought out and thoroughly unnecessary complication of what was a simple regular sound proposal. This proposed change to the Dresden definitions should not be made. -------------------------------------------------------------------------- -- Lawrie Schonfelder Honorary Senior Fellow University of Liverpool 1 Marine Park, West Kirby, Wirral, UK, CH48 5HN Phone: +44 (151) 625 6986