Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!uwm.edu!wuarchive!cs.utexas.edu!yale!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.fortran
Subject: Re: global data
Message-ID: <10652@lanl.gov>
Date: 8 Jan 91 18:49:27 GMT
References: <1991Jan08.143747.16553@convex.com>
Distribution: usa
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 54

From article <1991Jan08.143747.16553@convex.com>, by bleikamp@convex.com (Richard Bleikamp):
> [...]                                               For purposes of this
> discussion, let us assume one important use of MODULEs and INCLUDE will be
> the specification of interfaces to a library, and definition of some new
> types.  Both MODULEs and INCLUDE provide this capability.
>
> The use of modules to implement a 3rd party library essentially requires the
> 3rd party to ship source code.  [...]

Not true.  The proposed standard itself contains an example of how to
do this.  The interface specifications can be placed in a _different_
module than the code it specifies.  Only the source for the _interfaces_
need be shipped.  The _code_ can be shipped in binary form.

> [...]
> It is likely that compiler vendors will compile a MODULE into some
> intermediate representation, which could afford some protection to the
> 3rd party vendor who wishes to keep their source code secret; however,
> intermediate representations for MODULEs are very likely to suffer from
> rev-lock problems with each release of the compiler.  3rd party vendors
> (and computer manufacturers) can't release a new copy of each 3rd party
> library whenever the compiler is updated.

This is obviously an alternative to shipping the interfaces in a separate
MODULE.  The "rev-lock" problem (if it exists at all) will be no worse
than it is now.  After all, if the vendor wants to keep his source
private _now_, he ships binary - which is also subject to needing
revision when the compiler changes.  In fact, there is no reason that
the intermediate form of a MODULE need differ _at_all_ from binary for
that module.  The binary already needs to contain relocation information,
debugging information (as some form of symbol table), etc..  It might
as well _also_ contain any MODULE specific information.

> [...]
> Also, INCLUDE files are more portable across different machines, while
> intermediate representations of MODULEs will not be portable.

Again, if the vendor is trying to keep his source secret, he's shipping
binaries anyway.  What good does it do him to have portable interface
specifications if the code itself isn't portable?  Or, are you claiming
that binaries _are_ portable in some context where the intermediate
representations are not?

Further, INCLUDE is not _really_ all that reliably portable.  Read the
Fortran Extended document some time.  The INCLUDE feature is so vaguely
defined that a standard conforming compiler can do pretty much what it
likes with them - including ignoring them entirely.  You may not like
MODULES for some purposes, but at least they are well defined in the
proposed new standard.  I agree with you that _if_ INCLUDE were well
defined, there would be some things that it would be better at than
MODULE.  However, that is _not_ the case in the current proposed
standard.

J. Giles