Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!lll-winken!lll-lcc!ames!pioneer.arc.nasa.gov!maine
From: maine@pioneer.arc.nasa.gov.arpa (Richard Edwin Maine  D-OFA)
Newsgroups: comp.lang.fortran
Subject: Re: INCLUDE .vs. MODULE
Message-ID: <17231@ames.arc.nasa.gov>
Date: 28 Oct 88 04:53:47 GMT
Article-I.D.: ames.17231
References: <917@mace.cc.purdue.edu> <50500086@uxe.cso.uiuc.edu>
Sender: usenet@ames.arc.nasa.gov
Reply-To: maine@pioneer.arc.nasa.gov.UUCP (Richard Edwin Maine  D-OFA)
Organization: NASA Ames Research Center, Moffett Field, Calif.
Lines: 145


Several recent postings have debated the merits of the Fortran 8x
modules. My nickel's worth follows. These are all opinions based
my personal experience, about which I feel well qualified to
talk. I make no claim to represent the elusive "typical" user.

By the way, I am a user who does numerical applications for
flight data analysis.  I also spend a lot of my time helping
other users write and debug code.  I "confess" to having worked
towards a PhD that I never finished, but it was in engineering
instead of computer science, so that's ok.:-)

Modules are one of the parts of Fortran 8x that I was most
pleased to find on reading the draft standard. There were other
good things too, but modules were certainly high on my yes list,
close behind data structures. These are some of the kinds of
features that have occasionally driven me to use languages other
than Fortran. I may even be forced to go to ADA(tm) if Fortran 8x
doesn't happen sometime in the reasonably near future; please
save me from that!

Some of the postings have discussed modules versus include
statements. This comparison seems to ignore most of what I
thought, IMHO, that modules were about. (Ok, tell me I'm wrong,
but politely, please; my mother is really quite a nice lady:-)).

To me, the biggest thing modules are about is modularity. (Thus
the funny name, right)? This means program structuring,
information hiding, and lots of good buzz words like that. There
was a time when I didn't care much about that kind of stuff, as
long as I could compute the correct numbers. As the years have
passed, this has changed - a lot. Maybe I've just gotten lazy and
don't like to spend so much time debugging and maintaining the
codes. Some of my colleagues will claim I'm just getting senile
(at the tender age of 37 - alas). I prefer to think of it as
maturing my programming style, and I'd like to see the language
mature also.

I won't try to write a treatise on information hiding. Others
have done it far better than I can and at more length than is
appropriate here. Let me just say that it is really true that it
helps create more reliable programs that have better odds of
actually computing correct answers. I've killed many a bug from
related causes in code written by many people (myself included).
Conversely, I've found there have been far fewer bugs to kill in
my own code, once I got "religion" and started paying a lot of
attention to modularity and localization of information. Yes, you
can do it in Fortran 77, but the language fights you every step.

If you try to substitute include statements for modules, you tend
to get zillions of unneeded variables available to many routines
unless you work very hard at structuring the include files to
avoid it. Furthermore, you do not see the names of these
variables when you are editing the main source file (or when
looking at the listing file if the include files are omitted from
the listing, which they sometimes are). Add the fact that the
include file may have been written by somebody else and you have
almost guaranteed disaster. This happens for real; I've seen it.

Just like modules help hide information that should be hidden,
they help communicate information that should be communicated. I
think of modules as more of a replacement for COMMON blocks than
for include files. (Though I do agree that if you do use COMMON
blocks, which you need in Fortran 77, you should certainly do so
with include files).

COMMON blocks are burdened by too many strange restrictions and
are long overdue for overhaul. COMMON blocks cannot have
constants (though it is true that the include file containing the
common block may have symbolic constants; mine usually do).
COMMON blocks cannot be initialized except in Block Data, which
have a host of queer system dependent problems. COMMON blocks are
inextricably linked to memory association, which makes it tricky
to introduce very useful things like dynamically allocated
arrays. (I don't see how include files are going to help you make
globally accessible dynamically allocated arrays without modules
unless you introduce some other new language features).

Furthermore, many users are completely unaware of the quirks of
common blocks and this gets them in trouble regularly. I have had
many other users come to me complaining that xyz brand (it
varies) compiler is broken because, for instance, it won't
compile this data statement. They are almost uniformly shocked
when I tell them that the data statement won't compile because it
is illegal. After all, they always used to do things like that on
abc brand (also varies) compiler, so it must be legal.

Include statements often cause long compile times also. Try
writing a sizable graphics program that you have carefully
modularized into 100 or so small routines averaging 50 to 100
lines each. The vendor of the graphics package you are using has
provided an include file about 1,000 lines long defining the
various goodies needed for calling the graphics package. Since
Fortran 77 has no concept of global definitions, this include
file must be included in every routine that needs anything in it.
This does obscene things to the compilation time (in addition to
inviting bug infestations). I did not make this scenario up; I've
seen it often.

My usual countermeasure to the 1,000 line vendor-provided include
files is to extract just those definitions needed for my code
into my own smaller include file. However, this is 1) tedious; 2)
a maintenance headache; 3) an extra place for typographical or
other errors; and 4) just not applicable in some cases.

It is true that you can commit the same sins with modules and
that you can make good use of include files. I use include files
now, and I try to use them well; they beat the heck out of
manually putting (almost) identical COMMON statements in each
routine. My point is just that modules make it easier to do the
job better.

Yes, I'll confess that I'd like to see a virtually new language.
"If this be treason, make the most of it." - Patrick Henry. Some
of the things I would most like to see dropped from Fortran 8x
are some of the old features retained only for downward
compatability. Yes, I know lots of people disagree. Ok, keep the
features in the language, but I won't be using them. We already
have a language for those who think that Fortran 77 is perfect.
(Or even that the bugs in the previous version of their favorite
vendor's compiler were features that should not have been removed
in the current version. Yes, I've seen complaints like that, and
more than once).

What we do not have is a language for scientific work that
combines good error detection, clear syntax and power of
expression, efficiency, and portability. It isn't Fortran 77.
(The language of "DO 10 I = 1 100" and "IF (X) THEN A=1"). It
isn't c. (Some of my friends think otherwise, but it isn't for
me). It isn't Pascal or Modula. (As in "You want a what kind of
array? Well, if you insist, our compiler has a special extension
that..."). It isn't ADA. It isn't anything else that I know of,
and I've tried a pretty wide variety. Fortran 8x isn't perfect
either (what is?), but it could be a lot closer than any of
those others.  IF it happens, that is.

I'd like to see it and I'd be happy with the WG5 proposal or
something close to those lines.  And, of course, I'd like to
see it no later than a year ago, if not earlier.  Gosh, all
the time I've been wasting by using inferior languages.

Richard Maine
NASA Dryden, Edwards, Cal.
maine@pioneer.arc.nasa.gov - internet
maine@elxsi.dfrf.nasa.gov - preferred, but our internet conection
is only about a week old, so the other address might be safer.