Hello,

I will stay out of the heated OOP debate (I like parametrized OOP too, but it is
reality that this will not be part of the next Fortran, for good reasons--it is/was
too novel of a concept, as wonderful as it may be...), but I will comment on
SUBMODULEs:

> In such a case it would be better if the
> submodules were independently named and the choice of which ones were used
> left as an instruction to the linker.

I have a problem with this. In the current language, and in any good design of
future Fortran versions, a program should be self-contained, i.e. everything should
be in the source code. You can not postpone an association of an abstract procedure
interface with an actual implementation to the linker--somewhere there has to be
legal syntax that does this association, not related to the actual compilation
process. While I agree that the association may not need to be done in the parent
module, we'll have procedure pointers in F200x to deal with this run-time like
procedure association. I think your approach is basically equivalent to declaring a
few public procedure pointers in the module (I am not sure if this is allowed in
F2x). Leaving the submodule association to the linker is like associating a
procedure pointer with the linker instead of doing it in the program itself (before
the pointer is used of course).

In fact, I think that other novel F2x OOP features combined with procedure pointers
can be used to accomplish the breaking apart of "large projects" among multiple
programmers that you want. Submodules are in my view better viewed as simply an
extension of the body of the parent module, and will likely be coded by the same
programmer (just like one module is coded by one programmer). The advantage is of
course that we avoid cascade recompilation and also the submodule does not have to
be provided with the module to hide implementations. Also, although, as Van Snyder
mentions in the proposal, inlining and IPA will be made difficult with the
submodule structure, it is not impossible if the submodule is named inside the
module, but it will be impossible if only interfaces for the submodule procedures
are given without any specific association.

Although I agree with most of the other suggestions, such as allowing full
interface specifications for MODULE PROCEDUREs inside an interface block and also
using SUBMODULE FUNCTION/SUBROUTINE inside existing interface blocks, as well as
allowing the interface declarations to be repeated (identically in some sense) in
the SUBMODULE, the above is an important disagreement so I will wait to hear what
you think of it before commenting further.

Best,
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
__________________________________