Phillip Helbig wrote:
> What I guess you're suggesting is
>    MODULE BLABLA
>    USED_BY KLIMBIM, FOOBAR
> so that only the routines KLIMBIM AND FOOBAR can use MODULE BLABLA.

God forbid! That would kill the idea of code reuse. Any time I (the 
creator of a library, or perhaps many libraries) want to legitimately 
use my own creation as an auxiliary subroutine in the library, I'd 
have to edit its source and add the new module name to the USED_BY 
list. I hope this never happens.

Some time ago there was a discussion revolving around the topic of 
a flexible modules that could span many files and could be used to 
specify the public interface in a separate source file. I guess that 
discussion should be continued until someone (hopefully) proposes 
a solution that'll satisfy the majority (if not all) and provide 
the required functionality of separating the interface from 
the implementation.

To make the connection between the previous and the current 
discussion clearer, I'd like to build yet another example assuming 
that a single module has it's private part physically seperated 
from the public part (e.g., they reside in separate source files). 

  MODULE x PUBLIC
  ! .... contents of the public interface here

  ! A USE statement anywhere refers only to whatever is declared 
  ! in ths file.
  END MODULE x PUBLIC

  MODULE x PRIVATE
  ! All definitions and declarations from MODULE x PUBLIC visible 
  ! here and only here. All the private procedures that need not 
  ! to be revealed can be put here (and by definition they would 
  ! not be visible outside, as if they were PRIVATE in currently 
  ! existing modules).
  END MOODULE x PRIVATE

I don't foresee any need to duplicate anything with such a 
design. All module declarations and definitions need be written 
exactly once. It would be a question of style whether or not to 
allow the PRIVATE module part to repeat what's already declared 
in the PUBLIC part. 

If, e.g., you'd have a derived type XTYPE with some data publicly 
available and some private, then the only thing that would need 
to be repeated would be the type name.

In MODULE x PUBLIC you'd put
  TYPE XTYPE
     INTEGER i, j
  END TYPE XTYPE
and in MODULE x PRIVATE 
  TYPE XTYPE
     LOGICAL value_defined
  END TYPE XTYPE
The resulting type would be:
  TYPE XTYPE
     INTEGER i, j            ! PUBLIC
     LOGICAL value_defined   ! PRIVATE
  END TYPE XTYPE
and this would be stored in a binary module information file that 
a copiler typically creates. The user of a library would have free 
access only to the PUBLIC part of the module. All dependencies from
outside would refer only to the PUBLIC part. The very existence of
anything PRIVATE need not be known or, indeed, necessary to write, 
compile and link programs using the library.

BTW, I believe this scheme has shortcomings, some of which I know 
and some I don't. But perhaps it at least partially coincides with 
the direction in which we have to seek for a solution.

And a word about hand-coded separation (as above) vs. a tool 
that'd do it for us. I'd be glad if a tool which would generate 
the two parts of the MODULE above from a module written in the 
current style existed. I personally would rather write the 
separated interfaces myself. Question of taste, I guess. But if 
the F90 compiler recognized some form of such constructions as 
outlined above, then the tool to automatically generate two text 
files out of one would probably be rather easy to implement for 
a company that already has a Fortran compiler.

Regards,
----------------------------------------------------------------------
Artur Swietanowski                mailto:[log in to unmask]
Institut fuer Statistik,  Operations Research und Computerverfahren,
Universitaet Wien,  Universitaetsstr. 5,  A-1010 Wien,  Austria
tel. +43 (1) 407 63 55 - 120      fax  +43 (1) 406 41 59
----------------------------------------------------------------------


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