Path: utzoo!utgpu!watserv1!watmath!att!pacbell!pacbell.com!ucsd!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!uunet!convex!bleikamp
From: bleikamp@convex.com (Richard Bleikamp)
Newsgroups: comp.lang.fortran
Subject: Re: Is the INCLUDE statement standard?
Summary: More on INCLUDE/USE
Message-ID: <105636@convex.convex.com>
Date: 30 Aug 90 20:59:19 GMT
Sender: news@convex.com
Lines: 65

in a recent article,  wsb@boise.Eng.Sun.COM (Walt Brainerd) writes :
> ...
> Since it was only mentioned briefly, I thought I would expand
> a bit on the MODULE and USE of Fortran 90.  The main fact is
> that these will do everything (and much more) that INCLUDE will do.
> ...
> is already a candidate for the "obsolete features" list!
> ...

Well, part of this is kind of true, although MODULES will not replace INCLUDE
even when Fortran 90 is available everywhere.  Considering INCLUDE obsolete
is premature.  There are several "features" of modules that make them less
attractive than one might hope.  They are :

    1) 3rd party library vendors who wish to ship a MODULE or INCLUDE file to
       describe the interface to their library will almost certainly chose
       to use an INCLUDE file, for the following reasons :

       a) MODULES may need to be re-compiled with every Fortran compiler
	  release.  This creates unnecessary dependencies between a
	  3rd party product and the compiler.

       b) At the last Fortran 90 implementation symposium, the attendees
	  (including a number of X3J3 members) could not agree on whether
	  TWO or THREE modules would be required to define such an interface.
	  The problem is that 3rd party vendors don't want to ship
	  source code, just an interface definition, so the types to be
	  exported, etc., must go in a seperate module than the module
	  that contains the code (the reasons for this are too long to describe
	  here, but I'll be happy to e-mail an explanation on request).
	  The source code to the module defining the types/interface will be
	  shipped to users, but the module containing the code will be shipped
	  as an "object" (library or something else?).  The attendees could
	  agree on what the committees intent was, but were not at all sure
	  the language in the standard reflected the committees intent.

       c) Since the use of modules has not been standardized, it is impossible
	  for a 3rd party vendor to write ONE manual describing how to
	  use a library implemented via modules.  Include's don't have
	  this problem.

       d) A 3rd party vendor would need to generate seperate versions of each
	  module for each hardware/OS platform suppported, but can probably
	  get by with a single INCLUDE file.

    2) Item 1a applies to locally produced libraries as well.

    3) Pre-compiled modules (the "best" kind?) will share some attributes
       with Ada's dependent compilation model and diana net databases, namely,
       the implementation will be rather complex, and can be expected to be
       one of the buggier portions of Fortran 90 compilers for many years.  

Some of the problems with modules (and other language features) stems from the
X3J3 committees reluctance to standardize any part of the environment Fortran
programs execute in.

In summary, modules are well suited for packaging user defined data types
(and their overloaded operations), as well as packaging locally developed code
(modules are perfect for hiding implementation details), but are not a
generalized replacement for INCLUDE.

--
------------------------------------------------------------------------------
Rich Bleikamp			    bleikamp@convex.com
Convex Computer Corporation