John Bray <[log in to unmask]> expressed two concerns concerning the
J3 paper ftp://math.jpl.nasa.gov/x3j3/doc/meeting/153/00-197.ps.gz.

First, John remarked that the submodule approach requires that the
subprogram arguments be declared in a different place from the body
(if one uses the facility at all, which isn't required).

My first attempt at separating module specifications from module
bodies required the procedure body to repeat all of the specifications
of its interface, which presumably the compiler would check.  This is
the way that Modula and Ada work.  I have written substantial programs
in both languages, and have not found it burdensome to repeat procedure
interfaces.  Therefore, I was surprised to have gotten a lot of
complaints about it.  Several corresponents indicated that that feature
alone was enough to cause them to vote against it.  I got very few
remarks that prohibiting repetition of the interface would cause one
to vote against the paper.

There appears, however, to be a growing sentiment that repeating the
interface is the lesser of two evils.  There was also some discussion at
the last J3 meeting about allowing "benign redefinition," which in this
context means that it would be optional whether one wishes to repeat the
interface with the body.  I am inclined toward allowing this.  I am
interested to know the inclinations of others.

Second, John did not see how compilers would handle submodule information
so as to avoid compilation cascades.

The intent is that there is no submodule information that is visible to
program units that USE the module, or indeed to the module itself.
The only things visible are the entry names of procedures declared in the
parent module.  The only place those are needed is in linking, so in this
respect, submodules behave very much like external procedures.  Vendors may
produce a submodule information file in the case of submodules that have
submodules, because there is submodule information that is visible to
submodules of submodules, but changes in that file cannot affect the
module or users of the module.

Therefore, if one changes and recompiles a submodule, the only cascade
is downward in the submodule tree from that point, not upward into
the entire program tree.  I expect that most submodule trees would have
height two (module plus one level of submodules).  In this case, changing
a submodule produces no cascade whatever.

John's example

MODULE a
  INT :: fred
CONTAINS
  INCLUDE "sub1.inc"
  INCLUDE "sub2.inc"
END MODULE a

becomes

MODULE a
  INT :: fred
SUBMODULE :: A_SUB1
  subroutine SUB1 ( ... )
  end subroutine SUB1
SUBMODULE :: A_SUB2
  subroutine SUB2 ( ... )
  end subroutine SUB1
END MODULE a

SUBMODULE(a) A_SUB1
  real :: JOE
...
CONTAINS
  subroutine SUB1 ! ( ... )
  ! Body of Sub1
  end subroutine SUB1
! and maybe some REALLY private procedures that sub1 needs.  Neither A
! nor A_SUB2 can see them, nor are they visible in any other program unit
! except submodules that A_SUB1 may have.
END SUBMODULE A_SUB1

SUBMODULE(a) A_SUB2
  complex :: MARY
CONTAINS
  subroutine SUB2 ! ( ... )
  ! Body of Sub2
  end subroutine SUB2
END SUBMODULE A_SUB2

"USE A" accesses only "MODULE a", not "SUBMODULE(A) A_SUB1" or
"SUBMODULE(A) A_SUB2".  Both of the latter have (compile-time) access to
"MODULE a" but not vice-versa.  Therefore, compiling A_SUB1 has no effect
on how A is compiled, nor any program units that use A, nor indeed even
on A_SUB2 or any submodules A_SUB2 may have.

People who don't follow John's one-procedure-per-file discipline would
probably combine A_SUB1 and A_SUB2 into a single submodule.

John:  Perhaps you could tell me which passages of 00-197 you found
to be confusing concerning this issue, so that I can repair them.

Best regards,
Van Snyder






%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%