To: J3                                                     J3/25-119r1
From: Malcolm Cohen
Subject: US13 scoped access to module entities
Date: 2025-February-21
Reference: 23-196r1


1. Introduction

This paper discusses US13 "scoped access to module entities".

There are no requirements, specifications, or syntax proposed at this time.


2. Background

We already have renaming on the USE statement to manage name clashes
between entities imported from modules, and entities from a module with
locally-defined entities.

For example,

    Module module1
        Real var
    End Module
    Module module2
        Integer var
    End Module
    Subroutine eg
        Use module1,module1_var=>var
        Use module2,module2_var=>var
        Logical var
        var = .True.        ! My "var".
        module1_var = 1.5   ! The "var" in "module1".
        module2_var = 135   ! The "var" in "module2".
    End Subroutine

Special syntax for remote access to an entity in a module without renaming,
e.g. via a "special character" like "%" or ".", would not make this example
any longer, e.g.

        module1%var = 1.5
        module2%var = 135

Furthermore, module names are not passed through subsequent use or host
association, which means it would only work in a scope that directly uses
the module. That would make the feature useless. Passing module names
through use or host association, as class one identifiers (which they are),
cannot be changed without introducing an incompatibility.

Whereas, renaming produces a normal class one name that is already passed
through use and host association, so after renaming like the above, both
        module1_var and
        module2_var
can be used.


3. Possible kludges

Paper 23-196r1 suggests a syntax %%, and that module names pass through use
and host association only for the purposes of %%.

The problems here are simply:
    - this is quite inconsistent with how the scoping rules work;
    - module1%%var is still not any shorter than module1_var;
    - the module1_var solution to the problem has been available since
      Fortran 90, i.e. more than three decades.

Another possible kludge would be to allow module-name%%whatever to use
the module implicitly. But, this would complicate module dependency
analysis, which seems like a bad idea. If one wants to access a module
entity in a small piece of code without the "hassle" of documenting the
access in a USE statement at the beginning of the subprogram, one could
simply employ a BLOCK construct, e.g.
    Block
        Use module,only:mtol=>tol
        ! Set local tolerance to at least global tolerance.
        mytol = Max(mytol,mtol)
    End Block


4. Additional problems (or not) introduced by remote access

It has been suggested that USE-ONLY is sometimes used just to prevent
random conflicts, especially while a module is being developed, and that
therefore remote access should work through a USE-ONLY.

This idea has the potential to be useful in particular situations, but at
the cost of additional complexity, potential confusion, and rendering some
deliberate namespace controls ineffective.


5. Alternative ways of doing "similar" things

In earlier discussions on this topic, more advanced (or at least more
complicated) forms of namespace control were suggested. Perhaps further
investigation and development might be able to come up with a feature that
is at least as useful as remote access without the drawbacks that have been
identifier here. Such investigations should continue, whether they bear
fruit in time for Fortran 2028 (unlikely) or Fortran 203z (more likely),
or even if they never bear fruit.


6. Subgroup recommendations

After due consideration, subgroup considers that despite the initial allure
of the suggested remote access facility, it's benefit/cost ratio would not
only be small, but likely be negative (viz cure worse than the disease).

Subgroup recommends that this feature not be developed for Fortran 2028.

Instead, work should proceed on alternative ways as referred to in section
5, with a view to inclusion in Fortran 2028 if feasible and WG5 approves.

===END===