Hello,

> 1.  Should a submodule be
>     A.  a separate scoping unit that accesses its parent module or
>         submodule by host association, or
>     B.  an extension of the scoping unit of its parent?

I would agree with Wclodius@AOL [sorry!] in that the proposed extension to
modules is very much like other subprogram structure we have now, in which
the subsidiary entity accesses the parent's scoping unit via host
association. So I would leave the proposal to answer A.

> 2.  If the characteristics of a procedure are declared in a module and
>     its body is defined in a subsidiary submodule, should the body be:
>     A.  a separate scoping unit that accesses its characteristics by host
>         association, or
>     B.  an extension of the scoping unit of its characteristics, or
>     C.  something entirely different?

Here I would definitely vote for choice B (as it is too early in the morning
to think of a good answer to C--but I am rather uneasy about not even being
allowed to repeat the interface declarations when giving the body, as I find
it hard to think "across files" and would not mind repeating something that
almost never gets changed). The reason is that the way the proposal is
written now, the body of the submodule procedure is an *extension* of what is
already started in the procedure interface declaration. In fact, your current
proposal does not allow one to even repeat the declarations when giving the
body, so it is assumed that both the body and the interface declaration are
created by the same "master mind", right?

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? 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

> 1.  Should it be required to specify the submodule in which a procedure
>     body that corresponds to an interface is defined?
>
> 2.  Assuming the answer to question 1 is yes, should the submodule name
>     be specified in each interface, or in the header of a block
>     surrounding (potentially) several of them.
>
> As the draft of the technical report is presently written, the answer to
> question 1 is "yes," and the answer to question 1 is "in a block header."

I have no opinion as I am not quite sure what it would mean to answer 1 with
a no--how is the linker in the compiler know where to look for the actual
object code to link? Just specifying the interface is enough for the compiler
to compile the module, but then linking seems to me to require knowing where
the actual body is. Also, what would be (if any) an advantage of answering 1
with a no?

Before I answer 2:

> My objection to them is that interface bodies do not access their host
> environment by host association (which was, in my opinion, a substantial
> blunder).  Module procedures do, and if the technical report passes, so
> will submodules. It seems inconsistent to use interface bodies in this
> way.

I agree. It was a big blunder, and as I gather IMPORT is meant to fix this to
some extent. And although extensions to the functionality of interface blocks
are nice things, they do conflict with the F95 standard, so it is better to
replace them with something new, like your "procedure interface
declarations". I mean, in my opinion, there are other big blunders in F95,
such as some holes in the syntax of assumed-size-spec array declarations, but
it is rather difficult to correct these and still keep the old syntax and
semantics valid. Just a price to pay for backward compatibility, I guess.

> 3.  Should interface blocks and interface bodies be extended to take on
>     the duty of specifying the interface for submodule procedures?

No, mostly for consistency, although this is nice functionality.

Thanks,
Aleksandar

--
__________________________________
Aleksandar Donev
Complex Materials Theory Group (http://cherrypit.princeton.edu/)
Princeton Materials Institute & Program in Applied and Computational Mathematics
@ Princeton University
Address:
   419 Bowen Hall, 70 Prospect Avenue
   Princeton University
   Princeton, NJ 08540-5211
E-mail: [log in to unmask]
WWW: http://atom.princeton.edu/donev
Phone: (609) 258-2775
Fax: (609) 258-6878
__________________________________