From J.L.Schonfelder@liverpool.ac.uk Thu Jun 22 18:10:50 1995 Received: from mailhub.liverpool.ac.uk (mail.liv.ac.uk) by dkuug.dk with SMTP id AA01382 (5.65c8/IDA-1.4.4j for ); Thu, 22 Jun 1995 18:10:50 +0200 Received: from pop.liv.ac.uk by mail.liv.ac.uk with SMTP (PP); Thu, 22 Jun 1995 17:10:07 +0100 Received: from jlspc.liv.ac.uk (jlspc.liv.ac.uk [138.253.102.118]) by pop.liv.ac.uk (8.6.12/8.6.6-ajt-2) with SMTP id RAA08561 for ; Thu, 22 Jun 1995 17:05:28 +0100 Date: Thu, 22 Jun 1995 17:10:07 OBS From: Lawrie Schonfelder Subject: defect item 127 To: SC22WG5@dkuug.dk Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Charset: ASCII X-Char-Esc: 29 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. 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. -- Dr.J.L.Schonfelder Director, Computing Services Dept. The University of Liverpool, UK e-mail J.L.Schonfelder@liv.ac.uk phone: +44(151)794-3716 fax: +44(151)794-3759