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