I propose some questions below concerning the technical report to
allow one to divide modules into submodules.

Refer to the most recently published draft:

  ftp://ftp.nag.co.uk/sc22wg5/N1401-N1450/N1434.pdf or
  ftp://ftp.nag.co.uk/sc22wg5/N1401-N1450/N1434.ps.gz

I would like your thoughts concerning two questions about scoping issues
relating to submodules.

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?

The "A" alternative has the advantage of ease of explanation, because
"scoping unit" and "host association" are already defined terms.

It has the disadvantage that one might inadvertently re-define a module
entity in a submodule.

The "B" alternative has the advantage that one cannot redefine,
advertently or inadvertently, a module or submodule entity in a
subsidiary submodule

It has the disadvantage of difficulty of description:  The concept of
"being in the same scoping unit" would become nonsymmetric.  I.e., an
entity in a module would be in the scoping units of its submodules, but
entities in submodules would not be in the scoping unit of their parent,
or each other. A new concept, say a "scoping subunit" may be helpful.  The
scope of an entity would be the scoping unit or subunit in which it is
declared or defined, and all of its scoping subunits.  The scope of an
entity declared or defined in a scoping subunit would not extend to its
parent scoping unit or subunit.  This concept may be useful in describing
the scope of the names of components and type-bound procedures in
extension types.  Another term to define the same concept might be "an
extension of a scoping unit."

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?

Alternatives "A" and "B" have the same advantages and disadvantages as for
question 1, although in this case the disadvantages of alternative "B"
aren't as difficult, because a procedure interface has only one extension,
i.e., the body of the procedure, while a module may have several
submodules.

They both have the additional disadvantage that it is difficult or
impossible to describe the exceptional case of allowing (or requiring)
the characteristics to be re-specified in the submodule in which the body
is defined.

Alternative "C" has the disadvantage of not having any precedent, and no
expository framework on which to build.

It has the advantage that the expository framework could be built in such
a way as to permit the characteristics to be re-specified in the
submodule in which the body is defined.

The draft technical report is presently written to incorporate
alternatives 1A and 2B.  It specifies that the scopes of the names of
entities declared or defined in a child submodule do not extend into the
declaration of the characteristics in the parent module or submodule.
Because of the general "declare before use" rule, the only situation in
which a problem might have arisen is in the case of a type defined in the
characteristics in the parent module or submodule having a pointer with a
type defined in the body in the child submodule.

Van Snyder
[log in to unmask]