I've read the paper at
ftp://math.jpl.nasa.gov/x3j3/doc/meeting/153/00-197.ps.gz, and agree with
the description of the shortcomings of F90's module system. I'm not very
keen on the solution, as it seems to me (and I'm no expert on language
design) that the SUBMODULE approach would be awkward to use in practice,
for 2 reasons.
1) It would leave subroutine arguments a long way from subroutine bodies,
making code much harder to follow. There is no complete example in the
document, but wouldn't you get
MODULE a
SUBMODULE a1
SUBROUTINE sub1(var)
INTEGER, INTENT(INOUT) :: var
END SUBROUTINE sub1
END SUBMODULE a1
CONTAINS
SUBROUTINE a1
var = var + 2
END SUBROUTINE sub1
END MODULE a
This might be clear enough, but with multiple subroutines the declarations
and their use would get very far apart, and involve much scrolling back and
forth.
My code works on a policy of one subroutine per file for documentation
purposes, so Moda.f90 might look like
MODULE a
INT :: fred
CONTAINS
INCLUDE "sub1.inc"
INCLUDE "sub2.inc"
END MODULE a
and under the proposed approach I might have all arguments in the Moda.f90,
or in a further set of include files, leaving me with 2 files to view
whenever making a change. I think this would be impractical.
2) Its not clear to me how compilers would handle submodules information to
produce output files that would not cause compilation cascades.
John
--
John Bray, Numerical Weather Prediction Tel: +44 (0) 1344 854035
Room 337 [log in to unmask]
The Met. Office http://www.met-office.gov.uk
London Road, Bracknell, RG12 2SZ, UK http://www.jrbray.org.uk
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|