Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!yale!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.fortran
Subject: Re: global data
Message-ID: <10720@lanl.gov>
Date: 9 Jan 91 04:52:06 GMT
References: <1991Jan08.202010.3056@convex.com>
Distribution: usa
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 89

From article <1991Jan08.202010.3056@convex.com>, by bleikamp@convex.com (Richard Bleikamp):
> [...]
>     1) When you only include the INTERFACEs and global data for an external
>        library in a module, you have lost almost all the benefit of using
>        a module.  [...]

No one suggested this.  The interface specifications and global data are
in one MODULE, the code is in another - call them the interface and the
implementation MODULEs.  The implementation MODULE can still contain both
type definitions and the procedures that operate on those types: this
is the _main_ benefit of using MODULEs (encapsulation).  The implementation
MODULE can still contain PRIVATE data and procedures: this is the second
most important benefit of MODULEs.  Way down the list somewhere is the
ability to keep the interface specifications with the code it refers to.
This is the _only_ benefit you lose by separating the interface into a
different MODULE.  And, you can still do this, provided you don't mind
distributing the whole source.

>        [...]      INCLUDE provides the same capability.

Which is what I said to start off this line of discussion.  The word
"same" denotes an equivalence relation.  Equivalence relations are
symmetric (a=b implies b=a).  You say that INCLUDE provides the same
capability.  I began this thread by saying that MODULEs provide the
same capability.

> [...]
>     2) It is believed to be true that one module can contain the INTERFACEs
>        and global data definitions for a package, and another different
>        module can contain the source code for the routines.  This was 
>        discussed at one the fortran 90 implementation symposiums, and
>        we could not agree on whether two or three modules were required to
>        achieve the desired result.  [...]

I don't understand why three would be _required_.  The only thing that
requires even _two_ is the vendor constraint against distributing source.

> [...]                               This is at best convoluted, and unlikely
>        to actually work in the early Fortran 90 compilers.  [...]

Condemning a feature because of the possibility that the compiler won't
work can be applied to _all_ new features (and all old ones for that
matter).  I didn't find the definition of MODULEs all that difficult
to grasp.  Certainly, I think it's more likely to work on the early
compilers that KIND= stuff, or the POINTER attribute, or whole array
operations, etc..  But then, maybe I'm missing something.  Would you
care to elaborate about the kind of problems you anticipate (including
why you thought three separate modules might be needed)?

> [...]                                                  Usually, procedure
> call  mechanisms, and access to COMMON is not changed from one release to
> the next.  For MODULEs though, it is likely that some compiler data structures
> (such as symbol tables) will be contained in the intermediate representation
> of a pre-compiled MODULE.  This is almost certainly going to cause rev-lock
> problems. 

I don't understand.  The symbol table information should be contained
in _all_ binaries - not just MODULEs.  In fact, it should be transcribed
into the executable by the loader.  Otherwise, symbolic debugging is not
possible.  I realize that symbolic debugging on many small systems is
not yet the norm, but in professional quality environments it's essential.

In what important ways does a MODULE intermediate form differ from (say)
a C dot-oh file?  Both should contain symbol table info (as above).
Both should contain relocation info (obviously).  Both should contain
interface info (yes, even the C version - how else can the linker
actually verify that a procedure really matches the function prototype
that the calling routine claims?  What!?!?  Your C environment doesn't
do this?  How can you call yourselves ANSI C conforming? :-).  Both must
contain lists of all the globals that they use (that's part of the
relocation information).  Both must contain lists of all the globals
they declare (also part of the relocation information).  The both should
even contain descriptions of user defined types (derived types in
Fortran, unions and structs in C) - this info should be in a language
independent form in the symbol table.  Well, with all this info available,
the Fortran compiler should just learn to read binaries and it can get
all the MODULE info it needs - so forget about even having to split off
the interface stuff into a different MODULE, this should do it all.

To be perfectly honest, the only thing listed in the previous paragraph
that isn't routinely present in the object code (in a language-
independent form no less) on most production quality systems is
the interface information.  As I pointed out, even this info _should_
be present.  If it isn't, that's when you'll have to split the
interface specifications out of the implementation MODULE.  Whether
you put the interfaces into another MODULE of into an INCLUDE file
_should_ be an arbitrary decision.

J. Giles