Arthur and Philip have started to talk about some important
topics on modules.
In my view there are several shortcomings of modules that
need to be addressed.

-smart compilation: also avoiding compilation cascade, separation
 of interface and implementation. The latter is strongly argued for
 by Van Snyder (see his proposal 98-104,105,106 on the F2000 website
 http://www.ionet.net/~jwagener/j3/index.html)
 My view is somewhat different. This issue is and should remain a compiler
 problem. The code contains all the necessary information to construct
 the public interface which the compiler can use to check and determine
 whether the interface has been changed. The user should not be bothered
 to write an extra interface which will add to the workload and be
 error-prone. Interface checking is a perfect job for an automatic tool.
 I hope the compiler vendors are listening. This is 1998 and I don't see
 why we should not expect these kinds of management tools.

-encapsulation: modules provide only a very rudimentary way of
 protecting/hiding implementation details. Some of this applies to
 TYPEs as well.

 a) indirect use of modules
    MODULE Y
       USE X
       ...
    END MODULE Y
    MODULE Z
       USE Y
       ...
    END MODULE Z
    Now Z has also access to MODULE X (and W and V and ...) without
    saying a word. Only an explicit and global PRIVATE in MODULE Y
    will prevent this access cascade.
    (BTW this PRIVATE is a requirement in the F90 subset F.)
    This access rule is a very unfortunate default rule. The consequences
    for name conflicts are obvious.

 b) Unlike other languages like ADA95, Java, etc that also employ
    modules Fortran does not have a mechanism to qualify the
    procedures and variables used from modules.
    ADA uses WITH <module> which requires qualifying the used feature
    with the module name while an additionalUSE <module> allows to
    skip this, useful when only one module is used or is used a lot.
    This certainly takes care of naming problems.

 c) Privileged Access to internal and private details.
    This becomes very important for larger or more complicated codes.
    Fortran allows only PUBLIC or PRIVATE but does not provide anything
    more fine-grained. One could easily extend PRIVATE to PRIVATE(accesslist)
    where accesslist is a list of names of modules that have privileged
    access with the shortcuts PRIVATE(NONE) = PRIVATE, PRIVATE(ALL) = PUBLIC.
    PUBLIC/PRIVATE should become attributes of procedures as well instead
    of requiring an additional statement elsewhere in the module, e.g.

    FUNCTION, PRIVATE :: foo( args )

    This feature feature is also very useful for TYPEs,

TYPE, PUBLIC :: Person ! This refers to visibility outside module
Character, PUBLIC :: Name, First
Real, PRIVATE :: Age
END TYPE Person

    This would allow the programmer to give very fine-grained access
    control to other modules.

These features would also make it easier to develop some abstraction
levels in the code, starting with low-level modules which can only be
called in the next level but nowhere else, etc.

These issues become even more important in the context of object-oriented
programming in F2000 (see also my proposal 98-109 available in a day or
two from F2000 website).

Cheers,
WWS
-----------------------------------------------------------------------
| Werner W Schulz |
| Dept of Chemistry email: [log in to unmask] |
| University of Cambridge Phone: (+44) (0)1223 336 502 |
| Lensfield Road Secretary: 1223 336 338 |
| Cambridge CB2 1EW Fax: 1223 336 536 |
| United Kingdom WWW: |
-----------------------------------------------------------------------



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