Path: utzoo!mnetor!uunet!husc6!cmcl2!beta!a!jlg
From: jlg@a.UUCP (Jim Giles)
Newsgroups: comp.lang.fortran
Subject: Re: F8X response, MODULE vs. INCLUDE, ALLOCATE
Message-ID: <512@a.UUCP>
Date: 11 Mar 88 00:00:37 GMT
References: <1112@ut-emx.UUCP> <6690013@hpclcdb.HP.COM>
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 31
Summary: independent compilation

In article <6690013@hpclcdb.HP.COM>, cdb@hpclcdb.HP.COM (Carl Burch) writes:
> > 3) MODULE would inhibit independent compilation -- a BIG no-no in my world.   
> 
> You might note that INCLUDE is also dependent compilation - it's just
> uncheckable dependent compilation.  With MODULEs, the revision date can
> be checked by the compiler between the source and the preprocessed module 
> to ensure that your compilation is consistent.

Checking the revision date at compile time doesn't help.  Two seperate
routines might both use the module, but the routines might be compiled
seperately!  The loader is the only tool that can check the consistency 
of use.  Also, a checksum is better than a revision date.

Modules are involved with another inhibition of independent compilation.
Section 11.3.3.3.
    A derived data type may be defined in a module and accessed in a 
    number of program units.  This is the only way to access the same
    type definition in more than one program unit.

But this isn't really the fault of modules.  The committee should 
have allowed different program units to independently define a 
derived data type. 

Other than the above rule, modules do not inhibit seperate compilation
any more than include files do.  If you support include files, you
obviously oppose the rule in 11.3.3.3 already.  So, support for
include files eliminates seperate compilation as a valid objection
to modules.

J. Giles
Los Alamos