Aleksandar Donev <[log in to unmask]> wrote:
> ...
> But I am not understanding something here, so help me: In the draft, you
> say "a procedure in a submodule is logically a continuation of its
> interface in its parent program unit; it does not access its interface
> by host association". What does it mean to access one's interface via
> use association?
I'm sure the question was intended to be "... via _host_ association" so
I'll answer that question. If the body of the procedure in the submodule
were considered to be _inside_ of the interface in the parent, the
interface would be considered to be the host scoping unit of the body,
and the body could be considered to access the interface by host
association. As a consequence, one could override the declaration of,
say, a dummy argument, giving it a different kind, type or rank. If the
body is an _extension_ of its interface, the "no duplicate declaration"
rule would prevent this.
> And what happens with entitites declared in the
> specification part of the parent module. In question 1), answered with
> choice A, we say that the submodule can redefine these because it
> accesses them via use association. So now given asnwer B to question 2,
> does the submodule procedure access the original entity in the parent
> module or the redefined entity? What am I missing here:
>
> module example
> integer, save :: count ! Original declaration
> submodule :: sub_example
> subroutine test()
> end subroutine test
> end module example
>
> submodule(example) sub_example
> integer, save :: count ! Redefine count--OK with 1A, right?
> contains
> submodule subroutine test
> count=count+1 ! Which count is this now?
> end subroutine test
> end submodule sub_example
This is an excellent question, as it brings to mind an even more insidious
problem:
module example
integer, parameter :: MyKind = kind(0.0d0)
submodule :: sub_example
subroutine test ( Arg )
real(myKind) :: Arg
end subroutine test
end module example
submodule(example) sub_example
integer, parameter :: MyKind = kind(0.0e0)
real(myKind) :: Submod_Var
contains
submodule subroutine test
real(myKind) :: Temp
print *, kind(arg), kind(temp), kind(submod_Var)
end subroutine test
end submodule sub_example
What should "test" print?
As the draft stands, I would argue that it ought to print kind(0.0d0) twice
and kind(0.0e0) once. The reason is that myKind is accessed in the interface
of test, in the module, by host association. Since the body is an extension
of the interface, another declaration of myKind would violate the "no
duplicate declaration" rule. Bringing in a different myKind from the
submodule by host association could be viewed as another declaration, so it
ought to be prohibited.
If a submodule accesses its parent by host association, but a procedure
body is an extension of its interface, it appears that we get quite
complicated new host association rules; it would invite the same kinds of
conundrums as led to interpretation 80.
On the other hand, if the submodule were an extension of its parent,
there would be no question: It would be illegal to redefine myKind in
the submodule. Therefore, I'm starting to lean toward making the
submodule an extension of its parent, not a new scoping unit that
accesses the parent by host association.
This wouldn't prevent the body from accessing both the module and the
submodule by host association. The host of the body would be considered
to be one continuous entity, extending from the beginning of the module
into the submodule. The host would not be two entities, with one entity
(the submodule) inside of another one (the parent).
As I suggested in the original question, this would imply that the "in a
scoping unit" relation is not symmetric. An entity in the scoping unit
of a module is in the scoping units of all of its submodules, and all of
their submodules, etc., but an entity declared in the scoping unit of a
submodule is not in the scoping unit of the module, or any submodules
that are not descendant submodules of the one in which the entity is
declared. This is essentially the same as the relation between the
scoping unit of an extensible type and the scoping units of its
extensions. A natural consequence of this definition of "in the scoping
unit of the module" is that submodule entities are not accessible by use
association, just as components of an extension of a type are not
accessible by way of objects of the parent type.
Best regards,
Van Snyder
|