mwette@mr-edjpl.nasa.gov (Matt Wette) (08/29/90)
In article <1990Aug29.160951.19827@athena.mit.edu>, oliver@athena.mit.edu (James D. Oliver III) writes: |> Title pretty much says it all. I want to know, before I go replacing |> multitudes of common block and parameter statements, whether this is a |> standard command. I don't see mention of it in any FORTRAN 77 references, |> so I would assume it is not. If it's not standard, I'd like to know how |> portable I can expect it to be, i.e., which systems support it. |> |> -- |> ____________________________ |> Jim Oliver |> oliver@athena.mit.edu / joliver@hstbme.mit.edu |> oliver%mitwccf.BITNET@MITVMA.MIT.EDU The include statement is not standard, but I've never seen an implementation of Fortran compatible with Fortran 77 which did not support it. By the way, I find most Fortran 77 books which you find in computer or university bookstores do not provide complete descriptions of the language. One exception is H.Katzan, Jr., "Fortran 77," Van Nostrand Reinhold Co, New York, 1978, ISBN 0-442-25428-8 Matt _____________________________________________________________________________ Matthew R. Wette | Jet Propulsion Laboratory, 198-326 mwette@csi.jpl.nasa.gov | 4800 Oak Grove Dr, Pasadena,CA 91109 -----------------------------------------------------------------------------
Jeff Boyd <BOYDJ@QUCDN.QueensU.CA> (08/29/90)
I'd use INCLUDE whether it's standard or not (I don't think it is). If you send a package of mainprogs plus include files to another site where the compiler won't INCLUDE, the recipient need only use an editor to insert the include files back into the mainprogs.
oliver@athena.mit.edu (James D. Oliver III) (08/29/90)
Title pretty much says it all. I want to know, before I go replacing multitudes of common block and parameter statements, whether this is a standard command. I don't see mention of it in any FORTRAN 77 references, so I would assume it is not. If it's not standard, I'd like to know how portable I can expect it to be, i.e., which systems support it. -- ____________________________ Jim Oliver oliver@athena.mit.edu / joliver@hstbme.mit.edu oliver%mitwccf.BITNET@MITVMA.MIT.EDU
maine@elxsi.dfrf.nasa.gov (Richard Maine) (08/30/90)
On 29 Aug 90 16:09:51 GMT, oliver@athena.mit.edu (James D. Oliver III) said:
James> Title pretty much says it all. I want to know, before I go
James> replacing multitudes of common block and parameter statements,
James> whether this is a standard command. I don't see mention of it
James> in any FORTRAN 77 references, so I would assume it is not.
No, it's not standard Fortran 77. Yes, it is (will be, is proposed to
be, whatever) standard Fortran 90.
James> If it's not standard, I'd like to know how portable I can
James> expect it to be, i.e., which systems support it.
Almost all systems support something roughly equivalent. The exact
syntax varies somewhat, however. In my experience, the most widely
adopted syntax looks like
include 'filename'
with the include starting in column 7 or later just like a fortran
statement, and with quotes around the file name. This also happens
to be consistent with the proposed Fortran 90 standard syntax (Fortran
90 isn't picky about which column it starts in, but 7 is certainly
acceptable).
Compilers that I personally have used with this exact syntax include
Elxsi, Sun, Vax, Iris 4D (mips), IBM RS6000, and Lahey F77L (for IBM PCs
running DOS). Microsoft Fortran (IBM PC DOS) supports include, but with
a different syntax, which I don't recall without checking the manual.
My old Iris 3030 also uses a different syntax. The compilers on our
SEL GOULD (also known as Encore) systems running MPX-32 support include;
I think it was this syntax, but I'd have to recheck before I'd swear
it.
CDC Cyber systems running NOS (I don't know about the newer ones) did
not directly support include, but the UPDATE utility supported a
simillar facility with a different syntax; we tended to put our source
code in UPDATE libraries and let UPDATE do the inclusion as a
preprocessing step.
I really don't recall whether IBM mainframes do anything comparable.
(Perhaps it's a mental block that protects my sanity by erasing
most of the memories of the horrid years that I had to put up with
IBM mainframes).
On those systems with different syntax, it is pretty easy to write
an automatic procedure to change the syntax to the required form.
Often it's little more than a single line command.
If you are really paranoid, you can easily write an include
preprocessor in no more than about a screenful of standard
Fortran.
Thus, although include is not (currently) standard, it is reasonably
portable as long as you are willing to accept simple syntax
changing procedures. I find that the use of include saves me a lot
more time (mostly by assuring that my common blocks are *always*
consistent - a simple typo in one version of a common block can
cause many hours of debugging effort). The time saved is far
greater than the minor time spent on setting up a few automatic
syntax conversion procedures.
--
Richard Maine
maine@elxsi.dfrf.nasa.gov [130.134.64.6]t19@nikhefh.nikhef.nl (Geert J v Oldenborgh) (08/30/90)
> almost any Fortran will support it
Maybe, but the syntax will vary wildly; on the 3 systems I use they are
include 'file'
include file
#include 'file'
sed works overtime...
Geert Jan van Oldenborghsilvert@cs.dal.ca (Bill Silvert) (08/30/90)
In article <1990Aug29.160951.19827@athena.mit.edu> oliver@athena.mit.edu (James D. Oliver III) writes: >Title pretty much says it all. I want to know, before I go replacing >multitudes of common block and parameter statements, whether this is a >standard command. I don't see mention of it in any FORTRAN 77 references, Alas, it is not. This is my opinion the greatest problem with F77. One of the basic rules of good programming is that you do not rewrite identical code all over the place, and the INCLUDE statement makes this possible. Editing multiple copies of a COMMON block without introducing errors is always a risky proposition to undertake. Most compilers support INCLUDE, but with different formats. Some variants are: include file include 'file' $include:'file' along with variants of the F-90 (?) USE command. The only compiler I've had to use which does not support INCLUDE is the CDC Fortran, which is a real pain for that reason. Since I have to write portable code, I don't use any extensions -- but the INCLUDE statement is so essential that it is the one exception. -- William Silvert, Habitat Ecology Division, Bedford Inst. of Oceanography P. O. Box 1006, Dartmouth, Nova Scotia, CANADA B2Y 4A2. Tel. (902)426-1577 UUCP=..!{uunet|watmath}!dalcs!biomel!bill BITNET=bill%biomel%dalcs@dalac InterNet=bill%biomel@cs.dal.ca
mroussel@alchemy.chem.utoronto.ca (Marc Roussel) (08/30/90)
In article <MAINE.90Aug29222643@altair.dfrf.nasa.gov> maine@elxsi.dfrf.nasa.gov (Richard Maine) writes: >Almost all systems support something roughly equivalent. The exact >syntax varies somewhat, however. In my experience, the most widely >adopted syntax looks like > include 'filename' >with the include starting in column 7 or later just like a fortran >statement, and with quotes around the file name. >Compilers that I personally have used with this exact syntax include >Elxsi, Sun, Vax, Iris 4D (mips), IBM RS6000, and Lahey F77L (for IBM PCs >running DOS). Add to that list Apollo's machines. (The Apollo compiler supports both this syntax and one that requires passing your code through the C preprocessor. Yecchh!) Marc R. Roussel mroussel@alchemy.chem.utoronto.ca
leipold@eplrx7.uucp (Walt Leipold) (08/30/90)
In article <MAINE.90Aug29222643@altair.dfrf.nasa.gov> maine@elxsi.dfrf.nasa.gov (Richard Maine) writes: >I really don't recall whether IBM mainframes do anything comparable. >(Perhaps it's a mental block that protects my sanity by erasing >most of the memories of the horrid years that I had to put up with >IBM mainframes). Yes, recent IBM mainframe compilers (e.g., FORTVS) have an INCLUDE statement, but I found it completely useless because INCLUDE wasn't recursive (i.e., no INCLUDEd file could contain an INCLUDE statement). Another *fine* example of IBM's attention to detail... -- "As long as you've lit one candle, Walt Leipold you're allowed to curse the darkness." (leipolw%esvax@dupont.com) -- -- The UUCP Mailer
wsb@boise.Eng.Sun.COM (Walt Brainerd) (08/31/90)
In article <1990Aug30.105748.19204@cs.dal.ca>, silvert@cs.dal.ca (Bill Silvert) writes: > Most compilers support INCLUDE, but with different formats. ... > ... > along with variants of the F-90 (?) USE command. 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. (This won't help any until you get your Fortran 90 compiler.) And whether to include INCLUDE in Fortran 90 provides an interesting case study. Perhaps you will let folks on X3J3 know which way you feel about doing things like this in the future. Those who think that standards should (only???) codify "existing practice", felt that INCLDUE is an obvious example, since, as has been pointed out, virtually every compiler has an INCLUDE facility. However, as has been mentioned, some do it as a statement and some as a preprocessor (or compiler directive), some start in column 1 and some in column 7, some allow nested INCLUDEs and some don't, and there are many, many other small subtle things like whether it is permissible to have part of a Fortran statement in an INCLUDE and continue the statement in another INCLUDE or the including text. Those opposed to including INCLUDE argued that a) it won't standardize existing practice, because existing implementations are all different (even though, as R. Maine points out, it is easy to transform the syntax, it is not always easy to try to handle all the different rules and restrictions that vary from one implementation to another) and b) it is already (in F90) redundant given the MODULE/USE facility. The "compromise" was to put INCLUDE into Fortran 90, but make it very restrictive in the hope of matching the intersection of some of the many different implementations. Because of the redundancy, it is already a candidate for the "obsolete features" list! Perhaps you can guess how I feel about this. (The question is not whether it _useful_ when writing Fortran 77 programs; it is whether it should be _standardized_, requiring every implementation to conform to the description in the standard, which probably conflicts with what they have already, for the next 30-30,000 years, even if its usefulness ends.) As Maine also pointed out, one of the common(!) uses of INCLUDE is to make sure that your COMMON blocks match exactly in all routines that use them. In order to facilitate migration of existing programs to Fortran 90, it is possible to put COMMON blocks in a module. So, it is possible to take the instances of the COMMON blocks in your INCLUDE file and put MODULE-END MODULE around them and replace the INCLUDE statement with a USE statement. You may find, if your implementation of F90 is even a little bit clever, that the delcarations in the module will be "precompiled" and won't have to be reprocessed in each routine using them, as is the case with INCLUDEd text. Using modules to do really great things is the subject of a longer and more interesting story. -- Walt Brainerd Sun Microsystems, Inc. wsb@eng.sun.com MS MTV 5-40 Mountain View, CA 94043 415/336-5991
Jeff Boyd <BOYDJ@QUCDN.QueensU.CA> (08/31/90)
The VS Fortran 2.3 docs say that an INCLUDEd file can indeed contain further INCLUDEs, but not if the nested INCLUDEs give rise to a recursion, ie. an INCLUDEd file tries to INCLUDE itself. Nesting can go 16 levels deep.
bleikamp@convex.com (Richard Bleikamp) (08/31/90)
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
oliver@athena.mit.edu (James D. Oliver III) (08/31/90)
Many thanks to those of you who responded by e-mail and posting to my query. As usual, serendipity strikes again. ____________________________ Jim Oliver oliver@athena.mit.edu / joliver@hstbme.mit.edu oliver%mitwccf.BITNET@MITVMA.MIT.EDU
Jeff Boyd <BOYDJ@QUCDN.QueensU.CA> (09/05/90)
I routinely use source files for my INCLUDEs rather than TXTLIBs (or whatever equivalents exist on non-VM/CMS systems), so I indeed overlooked that possibility. I do think that source should always be within reach, especially when sending stuff off-site.
whit@milton.u.washington.edu (John Whitmore) (09/05/90)
In article <90241.151245BOYDJ@QUCDN.BITNET> BOYDJ@QUCDN.QueensU.CA (Jeff Boyd) writes: > >I'd use INCLUDE whether it's standard or not (I don't think it is). >If you send a package of mainprogs plus include files to another >site where the compiler won't INCLUDE, the recipient need only use >an editor to insert the include files back into the mainprogs. I used to think this way, too, until I found a set of programs in a text library (VAX/VMS). One can generate a long text file from the library (trivially). This text file can be ported to another machine. An attempt to compile runs into the following problem: there are INCLUDE statements that reference modules in the original library. The references are by module name (now lost...). The original FORTRAN compiler invocation had a switch that could be set so that any particular text library (or set thereof) could be searched to fulfill the 'INCLUDE' directives. The result was that the proposed scheme for porting the source code ran into a problem that could ONLY have been predicted by someone who knew in advance the INCLUDE usage (i.e. had read and understood almost all of the source code). Compiling any given program from the library required the programmer to explicitly require that the text library be searched, for any unresolved 'INCLUDEs. This was accomplished by an entry in a 'group logical name table' which few of the current group members remembered even existed. The upshot is that a LOT of research was required before anyone outside the group could handle the programs. Program maintenance requires INCLUDE capability, as well as some sort of version control (MAKE is a pretty well thought out tool), but for portability, one should make standalone long source files. There's no particular benefit to INCLUDE if the programmer has to remember (by wetware) which modules need the recompile before the next link. For me, INCLUDE solves too few problems. I avoid it. John Whitmore
dedina@cup.portal.com (Michael J Dedina) (09/07/90)
/In article <MAINE.90Aug29222643@altair.dfrf.nasa.gov>
/ maine@elxsi.dfrf.nasa.gov (Richard Maine) writes:
/>I really don't recall whether IBM mainframes do anything comparable.
/>(Perhaps it's a mental block that protects my sanity by erasing
/>most of the memories of the horrid years that I had to put up with
/>IBM mainframes).
/
/Yes, recent IBM mainframe compilers (e.g., FORTVS) have an INCLUDE
/statement, but I found it completely useless because INCLUDE wasn't
/recursive (i.e., no INCLUDEd file could contain an INCLUDE statement).
/Another *fine* example of IBM's attention to detail...
I *beg* your pardon; recent IBM mainframe compilers (VS Fortran) certainly
do accept *nested* include files. If you really wanted *recursive* include
files so your compiler can run all night in an infinite loop, then by all
means you need a different compiler.
Another *fine* example of a compiler-user's attention to detail...
/--
/"As long as you've lit one candle, Walt Leipold
/you're allowed to curse the darkness." (leipolw%esvax@dupont.com)
/--
/--
/The UUCP Mailer
Mike Dedina
dedina@cup.portal.com