J3/04-235 Date: 2004-02-10 To: J3 From: fortran.com Subject: New uses of the USE statement Reference: Pub-118 This was submitted by James Giles JamesGiles@att.net =========================================================== Number: Title: New uses of the USE statement Submitted by: J3 Status: For Consideration References: various, but particularls section 11 (FCD) Basic Functionality: Five parts. (1) allow an external procedure to USE a module that contains an INTERFACE block for the procedure itself. The meaning would be that the INTERFACE must match the declarations within the procedure. Otherwise, it will have the same meaning and rules as the USE of any other module. (2) allow a module procedure to USE the module that it is contained in. An unqualified USE of the module (that is, one without rename-list or ONLY) will have the same meaning that leaving it out has: all entities in the host will be imported by host association (including those with the PRIVATE attribute). The USE could contain a rename- list, in which case those items will be visible under the new name. The USE could have the ONLY keyword, in which case the names listed will be the only entities visible by host association. (3) allow an internal procedure to USE its host procedure as if it were a module. An unqualified USE would have the same meaning as leaving it out: all entities normally visible by host association will be imported into the scope. The USE could contain a rename-list, in which case those items will be visible under the new name. The USE could have the ONLY keyword, in which case the names listed will be the only entities visible by host association. (4) allow an INTERFACE block in a module to USE its host module. An unqualified USE of the module will mean that all entities in the host will be imported by host association (including those with the PRIVATE attribute). The USE could contain a rename-list, in which case those items will be visible under the new name. The USE could have the ONLY keyword, in which case the names listed will be the only entities visible by host association. (5) place the IMPORT statement on the obsolescent features list. Rationale: For (1), if a programmer, for whatever reason, chooses to write an external procedure, and declare an INTERFACE block for that procedure, the information about the interface has already been duplicated. The standard should permit compilers a convenient way of checking at compile-time that such information matches. And, paired with part (4), this feature allows type declarations and named constants (like KIND specifiers) to be conveniently shared between the procedure, its INTERFACE block, and other program units by just placing them in the module. For parts (2) and (3), the new feature allows control of the namespace within the procedure. You no longer need to inherit all of the entities of the host, nor by their original names. You can eliminate the danger of inadvertently associating something by host association when you actually intended to override with a local declaration. If an ONLY list is empty, nothing is visible by host association at all. For part (4), in addition to the purpose mentioned above in the rationale for part (1), this feature will allow abstract interfaces to be written that can reference the same host entities that the module procedures do. This means that it's conveniently possible to use that interface to describe procedure-valued dummy arguments and procedure pointer targets. whose associated procedures are intended to be one of the host's module procedures. This is the only really appropriate use of the IMPORT statement as well, hence the recommendation to make that statement obsolescent. Estimated Impact: On the plus side, it provides namespace control and compile- time checking in a number of places where the language has been deficient. But, the committee will have to consider some of the end-cases. For example: it may have already been decided, but is an INTERFACE block consistent with an external procedure's declaration if the arguments match in type, KIND, position, number, and other attributes even if the names do not match? Detailed Specification: Formal specification to be written as the result of debate and discussion. History: Submitted as Pub-118