(j3.2006) (SC22WG5.5472) J3/15-159 - J3 Fortran interp letter ballot #33 - due 24-Apr-2015

[Van Snyder]

On Thu, 2015-04-23 at 20:35 +0000, Bader, Reinhold wrote:
> Hello all, 
> 
> concerning Bills following comment
> 
> > 
> > Comment for F08/0128:
> > 
> > The discussion in this interp illustrates why the argument in 09-141
> > was wrong. I think a better answer for this interp is that passing
> > 09-141 was a mistake and it is being corrected by reinstating the
> > prohibition on a submodule using its ancestor.  An alternative, but
> > equivalent answer, is that there is no rational reason to allow use of
> > its ancestor module in a submodule, and the failure to prohibit this
> > is an error in the standard.

Another point to be made is that allowing access to the ancestor module
by use association raises the questions about visibility posed by the
interp.  The outcome that use association trumps host association might
be unexpected by students who haven't studied both rules, and their
interactions, carefully.  The interaction observed in the interpretation
is new, because accessing an entity by use association, that is already
accessed by host association, was impossible until 09-141.

> I agree that there is no need to allow use access to any entity from the ancestor 
> module in a submodule. However, I consider the following not only reasonable, 
> but also quite often necessary:
> 
> module mod_a
>   type :: a
>    ...
>   end type
> end module
> module mod_b
>   use mod_a
>   type :: b
>      type(a) :: a
>   end type
> end module
> submodule(mod_a) :: submod
>   use mod_b, only : b
> end submodule
> 
> This, I think, would also be prohibited if the old restriction is reinstated. The feature request that
> I handed in ended up as 08-154r1, but subsequently triggered an UTI, as far as I recall. Is there 
> any way to retain the above example as conforming? Note that the ONLY clause implies that no 
> entity from the ancestor module is accessed; any access to "a" inside the submodule would work via 
> host association.

The first note on page 7 of N1602 makes it clear that usage envisioned
during development of the TR was at least

module Mod_A
  ...
end module Mod_A
submodule(mod_a) :: Submod_A
  use b...
end submodule Submod_A

module Mod_B
  ...
end module Mod_B
submodule(mod_b) :: Submod_B
  use a...
end submodule Submod_B

The usage that Reinhold envisions would be useful, and we ought not to
prohibit it.  I don't think this can be handled in the general case,
especially if PRIVATE or PROTECTED entities are involved, by moving the
cross-using exclusively into the submodules, or by using a third module.