From janshep@watson.ibm.com Fri Jun 23 06:51:02 1995 Received: from watson.ibm.com by dkuug.dk with SMTP id AA04615 (5.65c8/IDA-1.4.4j for ); Fri, 23 Jun 1995 17:57:52 +0200 Message-Id: <199506231557.AA04615@dkuug.dk> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 7915; Fri, 23 Jun 95 11:57:08 EDT Date: Fri, 23 Jun 95 10:51:02 EDT From: "Janice C. Shepherd (8-784-6313)" X-Addr: H2-D52, Hawthorne I To: sc22wg5@dkuug.dk Subject: (SC22WG5.826) defect item 127 X-Charset: ASCII X-Char-Esc: 29 Lawrie Schonfelder wrote: >I copy the item from Janice's recent email ballot. I am strongly opposed to this >interpretation. It gratuitously complicates the users management of names to no >useful gain. A module name may well be global but it is in a different class (or >should be) to any other global or local name. The module name enters the program >only as a module name on a USE statement. It can occur in no other context. It >cannot be confused with any other use of the same name in any other context. I >can see that it might cause difficulties if a module name and another global >name were the same (module and main program names the same might cause >difficulties for some loaders) but I cannot for the life of me see any purpose >in defining module names to pollute the local name space. > The rule specified in Section 14.1.2 is quite clear on whether a global entity can have the same name as a local entity: [241:29-31] "Except for a common block name (14.1.2.1) or an external function name (14.1.2.2), a name that identifies a global entity in a scoping unit must not be used to identify a local entity of class (1) in that scoping unit." Lawrie observes - that a module is a global entity - that context is sufficient to differentiate between what is intended to be a module name and a local object of that name The same argument can be made for the name of a PROGRAM. So if we are going to add another exception to the rule that a global name cannot be the same name as a local name for modules, then we should also make an exception for PROGRAM names. But I'm not sure that this is the right direction for us to be going. Consider that the current exceptions to the rule (common block names, external function can be same name as its result variable) have long histories in the Fortran language. I would imagine that if the Fortran 90 syntax of "RESULT( )" had been included from the beginning then common block names would be the only exception to the rule. Even the common block name exception is a bit quirky... it is ok for a local entity to have the same name as a common block as long as the local entity is not a PARAMETER. While it is true that the context can be used to distinguish between a module name and a local name (and between a program name and a local name) it still adds unnecessary confusion to have a such double meanings for the same name. The set of valid names is sufficiently large that such duplicate uses should not be necessary. While the context is currently sufficient to distinguish between a module name and a local name, are we sure that some future feature added to the language might not best be handled by syntax that clouds that distinction? For example, there is currently a rule that if two module references cause two different objects with the same name to be accessible by use association then neither object must be referenced. A possible way of relaxing that rule is by allowing syntax such as %, but that syntax would be precluded if we relaxed the rules now to allow module names and local names to be the same. Consider that when it was first decided to make the function name be the name of the result variable, part of the argument pro that decision was likely "the two meanings are easily distinguished based on context". Functions that return arrays and recursive calls were not anticipated. So I don't think we should add more exceptions to the rule that a global entity and a local entity must not have the same name. I'd rather see us try to simplify the rule by making the exceptions obsolescent (eeks I can almost hear some users screaming at such a thought! :). Janice Shepherd > > >NUMBER: 000127 >TITLE: Is a module a global entity? >KEYWORDS: module, global entity, local entity >DEFECT TYPE: Interpretation >STATUS: X3J3 draft response > >QUESTION: Consider the following program fragment: > > MODULE ABC > INTEGER G > END MODULE > > PROGRAM MAIN > USE ABC ! Contains name ABC > REAL ABC ! Contains name ABC > > >JLS> ABC=0.0 ! there can be no confusion the ABC is the local real variable > > END PROGRAM > > >Question 1: Is a module a global entity? > >JLS> yes, but it is never a local entity. > >Question 2: In the above program fragment, the name ABC in the main program is >both the name of a module and of a local entity (of class (1)). May a local >entity of class (1) in a scoping unit have the same name as a module accessed >by that scoping unit? > >JLS> Yes as long as the name is not also a global entity name, such as the name >of an external procedure. > >Question 3: May a module be accessed in a scoping unit that also accesses a >local name that has the same name as the module? Specifically, in the example >below can subroutine SUB reference the variable ABC? > > MODULE ABC > INTEGER G > END MODULE > > PROGRAM MAIN > REAL ABC ! Contains name ABC > ... > CONTAINS > SUBROUTINE SUB > USE ABC ! Contains name ABC > ... > END SUBROUTINE > END PROGRAM >JLS> yes, the answer is the same as above. >ANSWER: >Answer 1: Yes, a module is a global entity. > >Answer 2: No, a local entity of class (1) in a scoping unit must not have the >same name as a module accessed by that scoping unit. > >Answer 3: No, a module can not be referenced in a USE statement in a scoping >unit that also accesses a local name that has the same name as the module. >Variable ABC is not accessible by that name in the subroutine SUB. > >Discussion: > >Discussion for Answer 1: > >The second sentence of Section 11 states that a module is a program unit. >Section 14.1.1 defines global entities. The definition includes modules >because the definition lists program units. > >In addition, the response to Defect Item 90 clarified the fact that a module >name is a global name by changing the following text in 12.1.2.2.1 >[163:39-164:1] from > > A name that appears in the scoping unit as an in an > is a global name... >to > A name that is declared to be an external procedure name (by an > or an ), or that appears as a > in a is a global name... > >Discussion for Answer 2: > >Answer 1 established that a module is a global entity and that a module name >is a global name. Section 14.1.2 states > > ... a name that identifies a global entity in a scoping unit must not > be used to identify a local entity of class (1) in that scoping unit. > >Discussion for Answer 3: > >There are two general cases where a local name could conflict with a module >name. The first is as follows where the local name is contained in the module >itself: > > MODULE ABC > REAL ABC > END MODULE > >and the second is as in the specific example provided above in Question 3. > >Section 11.3 [157:24-26] states: > > The module name is global to the executable program, and must not be the > same as the name of any other program unit, external procedure, or common > block in the executable program, nor be the same as any local name in the > module. > >This means that the first case is not standard conforming. > >Section 14.1.2 [241:29-31] states: > > Except for a common block name (14.1.2.1) or an external function name > (14.1.2.2), a name that identifies a global entity in a scoping unit must > not be used to identify a local entity of class (1) in that scoping unit. > >The original description of host association in 12.1.2.2.1 inadvertently failed >to account for module names. The response to Defect Item 90 supplies edits to >rectify the omission. With those edits, 12.1.2.2.1 now clearly states that the >appearance of a name as the in a prevents access by >host association to an entity of the same name in the host scoping unit. > >EDIT: None >SUBMITTED BY: Larry Rolison in X3J3/93-037 at m124. >HISTORY: 93-037 m124 Submitted > 93-097 m124 Draft response failed > 93-148 m125 Revised response, withdrawn > 93-235 m126 Revised response based on edit in item 82. approved uc > 93-255r1 m127 ballot passed 24-0 > HOLD per 82 > 93-327 m127 edits to 82, 90, 99, 127 approved uc > 94-034 m128 X3J3 ballot passed 27-0 > 94-160 m129 WG5 ballot failed > HOLD per 90 > 95-139 m133 Revised response based on edits in Defect Item 127, > draft response approved uc > >JLS> I will vote NO on this interpretation since I believe it to be bad language >design. If this means F95 requires edits to fix this problem then these edits >should be made. > >