J3/02-187 Date: 29 April 2002 To: J3 From: Kurt W. Hirchert Subject: Improving IMPORT =========== The Problem =========== Several deficiencies have been identified in IMPORT. On the mistaken assumption that IMPORT had not yet been implemented, I attempted unsuccessfully to address those deficiencies by replacing IMPORT with an alternative facility. In this paper, I attempt address these deficiencies be extending IMPORT rather than replacing it. The deficiencies I am attempting to address are the following: 1. It establishes host association with the wrong scoping unit (i.e., not the scoping unit that is the host of the procedure being described). [I know many committee members consider this a trivial problem, because there will rarely be a significant difference between what is available from the scoping unit IMPORT currently uses and what is available from the "right" scoping unit. I view it as being something like a two-foot-deep pothole by the side of a highway -- most people won't run into it, but it is better to repair it because of the damage it can inflict on those that do.] 2. It is inconvenient to use when the procedure being described makes extensive use of entities accessible by host association. 3. It makes interface bodies syntactically different from the procedures being described. 4. It doesn't address the impact of IMPLICIT on module procedures. ================== Possible Solutions ================== 1. The primary impact of the first deficiency is to cause plausible interface bodies not to work as intended because they access a different entity with a particular name. In existing successful usage of IMPORT, there should be little difference between importing from the "wrong" scoping and importing from the "right" one. Thus, it should be possible to redefine IMPORT to use the "right" scoping unit. Although this should be completely transparent for most existing uses IMPORT, it would be possible for an interface body to access information by host association that the procedure being described obtains in some other way. It might be better if such usage was reworked, but if we feel it important to support such oddities, we could add an option to _explicitly_ request that an interface access entities from the "wrong" scoping unit. 2. One way to make IMPORT more convenient to use would be to treat it like PUBLIC, PRIVATE, and SAVE -- have an empty list mean "everything" (in this case, everything not overridden). 3. If we can't get the IMPORT statement out of the interface bodies, then the other obvious way to get similarity between interface bodies and the procedures they describe is to allow IMPORT in those procedures. (There have been recent discussions on comp.lang.fortran asking for this kind of general control over host association.) 4. Currently, the inheritance of IMPLICIT rules is described separate from host association, even though they use essentially the same rules. We could fold this inheritance into host association and provide a syntactic form for describing this inheritance in the IMPORT statement's list. ======== Strawman ======== <> IMPORT[()][[::] ] <> NO IMPORT <> <> IMPLICIT([]) [Possible syntactic alternative; eliminate the "NO IMPORT" form and use "IMPORT()" (i.e., import from no host) instead.] If no IMPORT statement appears in a scoping unit, assume "NO IMPORT" in external scoping units and interface bodies, "IMPORT" for all other nested scoping units. All IMPORT statements in a scoping unit are required to have the same "" specification. The possible legal values for "" are the immediately surrounding scoping unit are the immediately surrounding scoping unit (if there is one), the host of that scoping unit (if there is one), the host of that scoping unit (if there is one), etc. (Since an external scoping unit has no legal values for "", it can only specify "NO IMPORT".) If "()" is omitted it defaults to the outermost legal value for an interface body and to the immediately surrounding scoping unit for all other nested scoping units. If the is omitted, all host entities not locally overridden are imported. The IMPLICIT([]) form controls use of the implicit typing rules from the host. If the is omitted, the rules for all letters are imported. [The above words are not intended to be "standardese", just an indication of how the "standardese" might be constructed.] ===== Edits ===== If this proposal receives a favorable response from the committee, I can produce a revision of this paper with edits. These edits should, for the most part, hit the same places as the edits in 02-247, with the addition that some of the text deleted from section 12 would be replaced in section 5. - end -