From WEAVER@stlvm7.vnet.ibm.com Thu Oct 1 19:53:52 1992 Received: from vnet.ibm.com by dkuug.dk via EUnet with SMTP (5.64+/8+bit/IDA-1.2.8) id AA03904; Thu, 1 Oct 92 19:53:52 +0100 Message-Id: <9210011853.AA03904@dkuug.dk> Received: from STLVM7 by vnet.ibm.com (IBM VM SMTP V2R2) with BSMTP id 1567; Thu, 01 Oct 92 14:56:06 EDT Date: Thu, 1 Oct 92 11:03:06 PDT From: WEAVER@stlvm7.vnet.ibm.com To: jls%liverpool.ac.uk@nsfnet-relay.ac.uk Cc: sc22wg5@dkuug.dk Subject: RFI - Host and USE association. X-Charset: ASCII X-Char-Esc: 29 You and I have about the same model. The reason I submitted the request is that I can't find text in the standard to support that model. I've inserted comments below. Thanks, Dick W. IBM D48/D332,555 Bailey Ave,PO 49023,San Jose Ca 95161-9023 internet: weaver@stlvm7.vnet.ibm.com 408-463-2956, fax ...-3114 ---------------------------------- >Date: Thu, 01 Oct 92 12:33:33 BST >From: Lawrie Schonfelder >Subject: (SC22WG5.226) Re: Request for interpretation - Host and Use associatio >To: WEAVER@stlvm7.vnet.ibm.com, SC22/WG5 members > >In-Reply-To: Your message of Wed, 30 Sep 92 16:07:34 PDT > >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. If they access the same things, then the lists of what they access (above) should be the same. One includes generic identifiers, one does not. One includes derived type components, one does not. etc. The equivalence proof should not be an exercise for the reader. >> Question 2: For both USE and host association, what entities are >> not accessed? >Trivially entities without names are not accessed. Well, common blocks can have names. Also, see question 3. >> 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. As you might have suspected, question 3 was my original question. I couldn't find the answer either. >> 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. That is my model too, but the text above doesn't support it. You write "B has access ..... that are accessible in A", but is there any text in the standard to support "accessible" in that context? All I find is "in A" or "from A" (and USE does not put things in A, it only makes something accessible from A). I've deleted question 5, the problem and discussion is a complete parallel to question 4. >> 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". Again, I think we agree but the standard doesn't support us. Host association only describes one level (163:34-35), as does Resolving generic names (244:1-20). Also, 14.1.2.4.1 describes a sequential algorithm. The difference between that and your productions would be when, and if, an ambiguous error is detected. You would detect it at every compilation in the process of building f{....}, the standard would detect them only when resolving a reference that was not resolved in a "lower level" scope. end.