From JLS@liverpool.ac.uk Thu Oct 1 13:46:12 1992 Received: from vm.uni-c.dk by dkuug.dk via EUnet with SMTP (5.64+/8+bit/IDA-1.2.8) id AA23714; Thu, 1 Oct 92 13:46:12 +0100 Received: from vm.uni-c.dk by vm.uni-c.dk (IBM VM SMTP V2R2) with BSMTP id 0651; Thu, 01 Oct 92 13:46:12 DNT Received: from UKACRL.BITNET by vm.uni-c.dk (Mailer R2.07) with BSMTP id 1587; Thu, 01 Oct 92 13:46:11 DNT Received: from RL.IB by UKACRL.BITNET (Mailer R2.07) with BSMTP id 0466; Thu, 01 Oct 92 13:46:04 BST Received: from RL.IB by UK.AC.RL.IB (Mailer R2.07) with BSMTP id 4263; Thu, 01 Oct 92 13:46:02 BST Via: UK.AC.LIV.LIVBIRD; 1 OCT 92 13:45:53 BST Received: from ibm.liverpool.ac.uk by liverbird.liverpool.ac.uk via JANET with NIFTP (PP) id <11330-0@liverbird.liverpool.ac.uk>; Thu, 1 Oct 1992 13:26:55 +0100 Received: from UK.AC.LIVERPOOL by MAILER(4.4.t); 1 Oct 1992 13:35:39 BST Date: Thu, 01 Oct 92 12:33:33 BST From: Lawrie Schonfelder Subject: Re: Request for interpretation - Host and Use association To: WEAVER@stlvm7.vnet.ibm.com, SC22/WG5 members In-Reply-To: Your message of Wed, 30 Sep 92 16:07:34 PDT Message-Id: <"liverbird..332:01.09.92.12.26.58"@liverbird.liverpool.ac.uk> X-Charset: ASCII X-Char-Esc: 29 On Wed, 30 Sep 92 16:07:34 PDT WEAVER@com.ibm.vnet.stlvm7 said: >QUESTION: > > Use association, 11.3.2 page 158, says > > "The USE statement provides the means by which a scoping unit access > named data objects, derived types, interface blocks, procedures, > generic identifiers (12.3.2.1), and namelist groups in a module." > > Host association, 12.1.2.2.1 page 163, says > > "An internal subprogram, a module subprogram, or a derived-type definition > has access to the named entities from its host via host association. > The accessed entities are known by the same name and have the > same attributes as in the host and are variables, constants, procedures > including interfaces, derived types, type parameters, > derived-type components, and namelist groups." > > Question 1: Do USE and host association access the same entities? > What entities does each access? Does this question mean are the same sorts of entities rendered accessible via USE and host association? I cant think of any that can be accessed via USE that cannot be accessed by host. > > Question 2: For both USE and host association, what entities are > not accessed? Trivially entities without names are not accessed. > > Question 3: For host and use association, if the host or module referenced > contains an EXTERNAL statement for ABC, is ABC an accessed entity that has > the EXTERNAL attribute? Note that an EXTERNAL stmt is not a "named > entity" (the statement has no name) and the procedure named in the > stmt is not in the host or module (that is why the EXTERNAL stmt). > > The answer to question 1 or 2 should also answer this question. I dont think the standard answers this question. The name ABC being that of an external procedure is globally accessible. But if I had MODULE MD EXTERNAL ABC ... PROGRAM P USE MD REAL ABC ! is this legal and what does it mean if it is? ... I have not found an definitive statement. If we had MODULE MD INTERFACE FUNCTION ABC(x) REAL :: x,ABC ENDFUNCTION ABC ENDINTERFACE ... The answer would be clear. The declaration in P would be a redeclaration of ABC which by the rules of USE association would be illegal. The explicit interface declared for an external procedure including the fact that it is external by an interface block is clearly made visible by USE. I would prefer the rule to be that EXTERNAL be not an attribute that is rendered visible by USE or host association. Since if it was it would not be possible for any other property of the interface to be declared. This would cause havoc if the external had a name and type that were different from those required by the local implicit typing rules. > > > Question 4: given the following > > PROGRAM A | MODULE M > USE X | USE Y > | > CONTAINS | > subprogram B | > USE M | > > is subprogram B associated in some way with X? What way? Note that A, > the host of B, "accesses" entities in X via USE association; the > entities in X are not "in" B's host. B has access by host association to all entities that are accessible in A, except where B actually declares an entity with the same name. This includes those names made accessible in A by USE association. > > > Question 5: in the same example > > is subprogram B associated in some way with Y? What way? As with > question 4 note that the entities in Y are "accessed" from M; the > entities in Y are not in M and USE association is to the entities > "in the module". Since B USEs M, B has access by USE association to all entities accessible in M except for those declared as private to M. That includes those accessed by USE association from Y. This produces a chain of USE associations where the multilevel visibility is controlled by the PRIVATE/PUBLIC declarations at each level. > > Question 6: given the following: > > Module a ! level 1 host > > use aa > interface f ! adds further overloads to f denote as ! f{aa,a} assumed to be unambiguous > ... > contains > > subroutine b ! module subroutine, level 2 host ! has host association access to f{aa,a} > use bb ! gains USE access to f{bb} to produce f{aa,a,bb} which must stll be ! unambiguous > interface f ! add further specific interfaces to get f{aa,a,bb,b} > .... > > contains > subroutine c ! internal subprogram ! host association gets f{aa,a,bb,b} > use cc ! USE adds f{aa,a,bb,b,cc} > interface f ! adds f{aa,a,bb,b,cc,c} > ... > .... = f(x) ! an invocation of the generic name f > ! invokes whatever specific procedure is selected ! form the whole set. What is the resolution if f{aa,a,bb,b,cc,c} contains the same specific proc interface body declaration more than once? I would have thought this was ok provided the interface was identically declared. > and where modules aa, bb, and cc all contain a generic interface for f: > > How is the invocation of the generic name f resolved? (in what sequence > are which hosts and uses considered?) The "sum" of all the accessible generic interfaces must be a valid overload set and so the overload should be unambiguous. > > Note the levels of nesting: a contains b contains c. Section 14.1.2.4.1, > Resolving procedure references to names established to be generic, > (3), seems to consider only "b", the host of "c", and not "a". > > >ANSWER: > > >REFERENCES: > ISO/IEC 1539:1991 (E) sections ..... > >EDIT: > >SUBMITTED BY: > >HISTORY: > ...... ... ..............................