From owner-sc22wg5@dkuug.dk Tue Sep 16 18:42:35 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h8GGgZQe068241 for sc22wg5-domo; Tue, 16 Sep 2003 18:42: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 mail22.messagelabs.com (mail22.messagelabs.com [62.231.131.211]) by dkuug.dk (8.12.8p1/8.9.2) with SMTP id h8GGgTCp068233 for ; Tue, 16 Sep 2003 18:42:30 +0200 (CEST) (envelope-from malcolm@nag.co.uk) X-VirusChecked: Checked X-Env-Sender: malcolm@nag.co.uk X-Msg-Ref: server-24.tower-22.messagelabs.com!1063730555!820851 X-StarScan-Version: 5.0.7; banners=nag.co.uk,-,- Received: (qmail 25959 invoked from network); 16 Sep 2003 16:42:35 -0000 Received: from smtp-1.star.net.uk (212.125.75.70) by server-24.tower-22.messagelabs.com with SMTP; 16 Sep 2003 16:42:35 -0000 Received: (qmail 9098 invoked from network); 16 Sep 2003 16:42:35 -0000 Received: from nagmx1.nag.co.uk (HELO nag.co.uk) (62.231.145.242) by smtp-1.star.net.uk with SMTP; 16 Sep 2003 16:42:35 -0000 Received: from brackley.nag.co.uk (brackley.nag.co.uk [192.156.217.21]) by nag.co.uk (8.9.3/8.9.3) with ESMTP id RAA25334 for ; Tue, 16 Sep 2003 17:42:29 +0100 (BST) Received: (from malcolm@localhost) by brackley.nag.co.uk (8.11.1/8.11.1) id h8GGiOi29008 for sc22wg5@dkuug.dk; Tue, 16 Sep 2003 17:44:24 +0100 (BST) (envelope-from malcolm) From: Malcolm Cohen Message-Id: <200309161644.h8GGiOi29008@brackley.nag.co.uk> Subject: Lawrie's comments on N1576 To: sc22wg5@dkuug.dk Date: Tue, 16 Sep 2003 17:44:24 +0100 (BST) X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-sc22wg5@dkuug.dk Precedence: bulk J.L.Schonfelder said: >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?? It's your perogative, but I don't see what making these email discussions into N-papers achieves other than the using up of N-numbers. BTW, I'll further note in passing that N1576 is rather sketchy on motivation and reasoning, giving a bare bones outline of the former and almost none of the latter. Before one starts leaping to conclusions about the reasoning prowess (or lack thereof) of the author(s) of the paper and the attendees at the meeting, perhaps we could have a dialogue, you know, where one asks things... just a thought. >I believe all these proposed changes to be unnecessary and undesirable. I'll take these in reverse order... >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 Indeed, that's why J3 recommended against doing it too! Unfortunately, this paragraph of N1576 was far from clearly written; it was reporting on a suggested change made (to J3) from a "real user" who was attending his first ever J3 meeting (hopefully he'll be able to get management support to attend many more, but that's by the by). After due consideration J3 decided not to pursue it, but Van dutifully reported the suggestion in the paper together with the main reason why J3 was not recommending it, but unfortunately left it up to the reader to deduce the lack of recommendation! So we're all (or at least most) in violent agreement on this one. >1. Management of the submodule name. I disagree comprehensively with almost all of this, including many of the claims of what the standard currently says about global entities. >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. This is a perfectly good rationale for there being no need to have a "name clash" (with local entities); however, it is not what the standard says now nor is it what it would say after incorporation of the Dresden version of the TR. I'll just go through the gory details as per the Dresden version: (1) the submodule name is that of a global entity [it is a program unit, so a global entity by 16.1] (2) a name that identifies a global entity in a scoping unit is prohibited from identifying a local entity of class (1) in that scoping unit. [second paragraph of 16.2] i.e. Lawrie's conjecture that submodules "don't clash" with local entities is unfortunately untrue - they clash with the most important class of local entities! Now going through the N1576 version: (1) the submodule name is local to the module (2) the submodule name is of "class (4)", so ********************************************** * IT ONLY CLASHES WITH OTHER SUBMODULE NAMES * ********************************************** i.e. the N1576 version actually achieves what Lawrie believes (sadly, mistakenly) already to be the situation. >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. The standard does not draw a distinction here. > A submodule name must be global in the same sense as a module name >must be global if it is used. Again, the standard does not draw a distinction. Lawrie is, I think, postulating about implementation techniques. In particular, whether a Fortran "global entity" is a "linker symbol". I have it on the very best of authority that there has indeed been at least one Fortran 90 implementation where module names were indeed "linker symbols", and that there were good reasons for that decision (in that implementation). >To have two submodules of the same name with the same ancestor could be >a source of problems and probably should be disallowed. Well, no-one is currently proposing such a thing. > 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. There appears to be no technical reason for this restriction. Seriously. >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. This analysis has forgotten that large projects also (rather often) use third-party libraries. It would be highly undesirable for the language to expose the internal structure of the third-party library, in the form of its submodule names. Not to mention that separate parts of a large project don't want to have to have some stupid naming convention to avoid clashes between their submodule names. There's no good reason to impose this on them. Indeed, other than the "compilation cascade" (which is actually solvable by technological rather than language features anyway), avoiding this sort of internal structure exposure is the whole point of doing submodules. One might as well use modules (not submodules) with a naming convention if you're going to have to use the naming conventions anyway. Personally, I thought the "submodule names are global" was one of the weakest aspects of the Dresden TR, being in opposition to one of the TR's stated objectives. > 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). Then why on earth are you trying to keep them in the same name space (the "global" one)? It's no good saying "there is no need" for the implementor to do certain things if in fact the language standard ENCOURAGES him to do so. Making linker symbols and other "global" internal implementation usage for what the standard says are "global" entities is not only feasible, it is highly likely! If we want to achieve "submodule names are not global", the way to go about it is to write the standard that way! History tells us that making assumptions about what is reasonable/natural/easy for an implementation in the absence of specification leads to variance between implementations, the enemy of portability. >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. I don't see the massive undesirability myself. For "small" uses of submodules (where name clashes are likely to be rare anyway), the user is likely to have only one level of submodule and therefore there is NO CHANGE with or without the N1576 change. And for forests of large structured submodule trees, mentioning the ancestor module (only one, however deep) is very little burden and indeed could be considered to be valuable documentation! As mentioned above, I think this suggestion in N1576 (that submodule names be "class 4", local to the module, and incidentally not accessible via use or host association) is an excellent one fixing what was to my mind one of the few remaining weak features of the submodule TR. Cheers, -- ...........................Malcolm Cohen, NAG Ltd., Oxford, U.K. (malcolm@nag.co.uk) ________________________________________________________________________ This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ________________________________________________________________________