Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!samsung!uunet!pmafire!uudell!bigtex!texsun!male!newstop!exodus!road.Eng.Sun.COM!corbett
From: corbett@road.Eng.Sun.COM (Robert Corbett)
Newsgroups: comp.lang.fortran
Subject: Re: global data
Message-ID: <5535@exodus.Eng.Sun.COM>
Date: 9 Jan 91 06:07:44 GMT
References: <1991Jan08.143747.16553@convex.com> <10652@lanl.gov>
Sender: news@exodus.Eng.Sun.COM
Distribution: usa
Organization: Sun Microsystems, Mt. View, Ca.
Lines: 33

In article <10652@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>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

You have got to be kidding.  The specification of MODULEs in
Fortran Extended leaves so much up to the implementor that
there are liable to be dozens of incompatible implementations
(assuming there are dozens of implementations).

There is nothing in the standard that requires an implementor
to allow a MODULE to be referenced in a file other than the
one in which it is defined.  As Section C.11.3 states,

     The exact meaning of the requirement that the public
     portions of a module be available at the time of
     reference is processor defined.

I complained about the need for tighter requirements on the
rules for MODULEs in the first two public reviews and was
told that it is a quality of implementation issue.  It is now,
but it need not have been.

					Yours truly,
					Bob Corbett