Fortran - 50th birthday of Fortran

Author

50th birthday of Fortran

beliavsky@aol.com

2006-07-20, 7:00 pm

The first Fortran compiler was released in 1957, so Fortran will turn
50 next year. There will be a meeting on the history of Fortran in
London in January 2007, details at
http://www.fortran.bcs.org/2007/jubileeprog.php . I hope that
presentations will be made available online. I wonder if there will be
a U.S. event.

Terence

2006-07-20, 7:00 pm

SInce my involvement with Fortran in IBM, in 1961, and my later
programming life, the progression through the different versions has
for me been positive.
I know very many programming laguages but only Pascal and Fortran have
really attracted me.

>From the removal from Fortran of the early SENSE light displays and
SENSE Switch tests, and later, the ugly ASSIGN with the GOTO variable,
we have made huge progress right up to and through F77. Especially I
liked the introduction of the IF..THEN..ELSE which helped to remove
label counts and facilitate large compilations on small machines.

However I still prefer the computed GOTO over the CASE alternative,
even though the variable had to be monotonically increasing for the
GOTO version. And I still wonder if anything important has been gained
with F90 beyond the valuable full checking of variables between
subprograms. Way, way back, PL/1 introduced matrix arithmetic which was
a long time coming with Fortran.

My point is: is Fortran programming now becoming more difficult and
exacting?
Were the advances beyond F77 more academic than truly advantageous?

Windows programming required a new look at Fortran Compilers, which I
accept; but perhaps it is Windows itself that is the problem?
And new CPU chips need newer updated compilers but not a new form of
the language, apart from OCCAM-like multiprocessing forms of the
language.

Terence Wright.

Brooks Moses

2006-07-21, 3:59 am

Terence wrote:
> My point is: is Fortran programming now becoming more difficult and
> exacting?
> Were the advances beyond F77 more academic than truly advantageous?

The first programming language that I was formally taught was Fortran 77
in my freshman-year introduction to engineering course. I learned most
of it the summer before college, by reading the class textbook in the
evenings while on a family RV-camping trip around Alaska.

Several years later, when I started on my doctoral research I was using
a 6500-line CFD code written in Fortran 77, which I eventually replaced
by a similar program I wrote myself, also in Fortran 77.

A few years ago, I converted that program to Fortran 95 in a relatively
trivial way (by moving COMMON blocks into modules, changingg fixed-size
"big enough" arrays to allocatables, and converting the files to
free-format source, mostly), and immediately fixed a few bugs that were
lurking due to my having changed the array limits in almost but not
quite all the COMMON blocks.

Since then, I've been writing a fair number of complicated CFD-related
utilities in Fortran 95, which have been much more in "real" F95 rather
than just trivially-converted F77. I am finding that the advances made
since 1977 are making my programming considerably easier and more
straightforward.

For instance, in a code which handles large CFD data arrays with sizes
unknown until a parameter file is loaded at runtime, I think that the
value of allocatable arrays is relatively obvious; particularly with the
TR15581 additions, they're tremendously better than any way Fortran 77
had to deal with arrays with sizes that couldn't be determined at
compilation. (And, yes, there were times where I expected to need to
recompile the program before nearly every run, in order to change the
array sizes.)

User-defined data types, aside from being generally convenient, are
invaluable for reducing large sets of parameters (or, for that matter,
numbers of arrays) to a single item in a procedure argument list. In
the early CFD codes I was using, passing everything by arguments was
sufficiently unweildy that it was easier to use ten or twenty lines of
COMMON blocks instead, which was error-prone and not especially clear at
all.

Modules (and other options for non-external procedures) are also quite
useful, in that they remove the need for duplicate declarations of
functions wherever they are used, and make it much more likely that
argument mismatches will be discovered by the compiler. Having been hit
by bugs of that sort before, and having found them quite difficult to
track down at least once or twice, I find that this makes things a lot
easier.

I could go on, but that's probably enough. It might possibly be that,
because the language is growing, reading other people's Fortran programs
is becoming more difficult. (I would contest even this, though; the CFD
program I started with was very difficult to read in part because of the
convolutions needed to do certain things without user-defined data types
and some of the more recent block structures.) However, I find that it
is most definitely easier for me to write clear high-quality programs in
Fortran 95 than in Fortran 77.

- Brooks

--
The "bmoses-nospam" address is valid; no unmunging needed.

Mark Westwood

2006-07-21, 4:00 am

Yup

I second what Brooks wrote wrt the genuine advances from FORTRAN77 to
Fortran 90/95. I'll even admit to looking forward to features of
Fortran 2003 and 2008 filtering through.

Here's to another 50 years for all of us, Fortran included.

Mark Westwood
Parallel Programmer

Brooks Moses wrote:
> Terence wrote:
>
> The first programming language that I was formally taught was Fortran 77
> in my freshman-year introduction to engineering course. I learned most
> of it the summer before college, by reading the class textbook in the
> evenings while on a family RV-camping trip around Alaska.
>
> Several years later, when I started on my doctoral research I was using
> a 6500-line CFD code written in Fortran 77, which I eventually replaced
> by a similar program I wrote myself, also in Fortran 77.
>
> A few years ago, I converted that program to Fortran 95 in a relatively
> trivial way (by moving COMMON blocks into modules, changingg fixed-size
> "big enough" arrays to allocatables, and converting the files to
> free-format source, mostly), and immediately fixed a few bugs that were
> lurking due to my having changed the array limits in almost but not
> quite all the COMMON blocks.
>
> Since then, I've been writing a fair number of complicated CFD-related
> utilities in Fortran 95, which have been much more in "real" F95 rather
> than just trivially-converted F77. I am finding that the advances made
> since 1977 are making my programming considerably easier and more
> straightforward.
>
> For instance, in a code which handles large CFD data arrays with sizes
> unknown until a parameter file is loaded at runtime, I think that the
> value of allocatable arrays is relatively obvious; particularly with the
> TR15581 additions, they're tremendously better than any way Fortran 77
> had to deal with arrays with sizes that couldn't be determined at
> compilation. (And, yes, there were times where I expected to need to
> recompile the program before nearly every run, in order to change the
> array sizes.)
>
> User-defined data types, aside from being generally convenient, are
> invaluable for reducing large sets of parameters (or, for that matter,
> numbers of arrays) to a single item in a procedure argument list. In
> the early CFD codes I was using, passing everything by arguments was
> sufficiently unweildy that it was easier to use ten or twenty lines of
> COMMON blocks instead, which was error-prone and not especially clear at
> all.
>
> Modules (and other options for non-external procedures) are also quite
> useful, in that they remove the need for duplicate declarations of
> functions wherever they are used, and make it much more likely that
> argument mismatches will be discovered by the compiler. Having been hit
> by bugs of that sort before, and having found them quite difficult to
> track down at least once or twice, I find that this makes things a lot
> easier.
>
> I could go on, but that's probably enough. It might possibly be that,
> because the language is growing, reading other people's Fortran programs
> is becoming more difficult. (I would contest even this, though; the CFD
> program I started with was very difficult to read in part because of the
> convolutions needed to do certain things without user-defined data types
> and some of the more recent block structures.) However, I find that it
> is most definitely easier for me to write clear high-quality programs in
> Fortran 95 than in Fortran 77.
>
> - Brooks
>
>
> --
> The "bmoses-nospam" address is valid; no unmunging needed.

Catherine Rees Lay

2006-07-21, 8:00 am

Brooks Moses wrote:
>
> I could go on, but that's probably enough. It might possibly be that,
> because the language is growing, reading other people's Fortran programs
> is becoming more difficult. (I would contest even this, though; the CFD
> program I started with was very difficult to read in part because of the
> convolutions needed to do certain things without user-defined data types
> and some of the more recent block structures.) However, I find that it
> is most definitely easier for me to write clear high-quality programs in
> Fortran 95 than in Fortran 77.
>

I think you're right about reading other people's code becoming more
difficult in some cases. While I write Fortran 95, there are areas of
the language that I've never needed to use yet. If a code makes
extensive use of, say, TRANSFER, or generic procedures, I'm going to
have to put more effort in to understand it. With F77 I was fairly
confident that I was familiar with all of the language. There's just too
much of F95 for me to feel that way.

Which isn't necessarily a bad thing. If the same code was written in F77
I'd understand the code faster, but have to spend more time on figuring
out what the algorithm behind it is.

Catherine.

David Flower

2006-07-21, 8:00 am

Terence wrote:
> SInce my involvement with Fortran in IBM, in 1961, and my later
> programming life, the progression through the different versions has
> for me been positive.
> I know very many programming laguages but only Pascal and Fortran have
> really attracted me.
>
> SENSE Switch tests, and later, the ugly ASSIGN with the GOTO variable,
> we have made huge progress right up to and through F77. Especially I
> liked the introduction of the IF..THEN..ELSE which helped to remove
> label counts and facilitate large compilations on small machines.
>
> However I still prefer the computed GOTO over the CASE alternative,
> even though the variable had to be monotonically increasing for the
> GOTO version. And I still wonder if anything important has been gained
> with F90 beyond the valuable full checking of variables between
> subprograms. Way, way back, PL/1 introduced matrix arithmetic which was
> a long time coming with Fortran.
>
> My point is: is Fortran programming now becoming more difficult and
> exacting?
> Were the advances beyond F77 more academic than truly advantageous?
>
> Windows programming required a new look at Fortran Compilers, which I
> accept; but perhaps it is Windows itself that is the problem?
> And new CPU chips need newer updated compilers but not a new form of
> the language, apart from OCCAM-like multiprocessing forms of the
> language.
>
> Terence Wright.

I suspect that part of the problem is that the wrong question was asked
about what was wanted in F90.

The question that should have been asked is:

What is missing in F77 ?

and what was added in F90 included much that did not significantly
increase functionality (e.g. Free form source), and illustrated neglect
of the maxim 'If it ain't broke, don't fix it'.

I accept that much useful was added with F90, but compared with the
transition of F66 to F77, the improvement was minor. As a programmer
who had to code without either OPEN statements, or CHARACTER variables,
I can attest to that.

Dave Flower

Brooks Moses

2006-07-21, 7:01 pm

David Flower wrote:
> The question that should have been asked is:
>
> What is missing in F77 ?
>
> and what was added in F90 included much that did not significantly
> increase functionality (e.g. Free form source), and illustrated neglect
> of the maxim 'If it ain't broke, don't fix it'.

Have you ever owned a car where the tie rod ends were going bad, so that
the steering had gotten terribly loose? Since it happens slowly, the
owner of the car is usually unaware that they're turning the steering
wheel this way and that to keep the car going straight, and have no
problem with it, but anyone who's not used to it has a difficult time
keeping the car on the road.

Fixed-form source is a lot like that. From the perspective of most
people who haven't been using it for several years, it's definitely broken.

- Brooks

--
The "bmoses-nospam" address is valid; no unmunging needed.

Joe Krahn

2006-07-21, 7:01 pm

Terence wrote:
....
> However I still prefer the computed GOTO over the CASE alternative,
> even though the variable had to be monotonically increasing for the
> GOTO version. And I still wonder if anything important has been gained
> with F90 beyond the valuable full checking of variables between
> subprograms. Way, way back, PL/1 introduced matrix arithmetic which was
> a long time coming with Fortran.
Once you develop a system for numeric labels, it is hard to change your
routine. They can help give a sense of code layout for navigation, but
no immediate meaning. A GOTO with a list of numbers is quite cryptic. I
would much prefer named labels. A system of 'label 999 is the
error-return line' is less readable than a named label "GOTO
error_return", but can work well for the programmer who knows the 'rules'.

>
> My point is: is Fortran programming now becoming more difficult and
> exacting?
> Were the advances beyond F77 more academic than truly advantageous?
>
Much of the post-F77 evolution has been encumbered by politics and
different opinions of the right way for Fortran to go. The result is a
language that is in some ways too complex for the number of features,
some of which seem incomplete, and a whole generation of people dumping
Fortran for C. Fortunately, some of the annoyances are finally getting
fixed. The next generation of Fortran will be a big improvement, with
enough object-oriented stuff to be usable, but not so much to get in the
way.

My overall opinion is that much of the stuff beyond F77 has good
intentions, but not really done right. The two general things I dislike
are the excess verbosity, and the excess strictness. In terms of
strictness, there is a big di

vantage of being able to cast pointers.
Even F77 can do this indirectly via dummy arguments. Maybe there was
some over-reaction to excessive use of EQUIVALENCE and COMMON hacks.

> Windows programming required a new look at Fortran Compilers, which I
> accept; but perhaps it is Windows itself that is the problem?
> And new CPU chips need newer updated compilers but not a new form of
> the language, apart from OCCAM-like multiprocessing forms of the
> language.
>
Windows is definitely a problem. It has a horrible shell for text-based
operation, and the system is very non-compliant with POSIX and even
ISO-C. Even with ISO_C_BINDING, Windows will still need a bunch of
non-standard directives to work with C.

Personally, I had decided that Fortran is doomed. But, F2003
developments (and beyond) along with the chaos of doing math in C++,
have really gotten me enthusiastic about Fortran. Maybe the 50th
anniversary can be a turn-around point.

Joe Krahn

Paul Van Delst

2006-07-21, 7:01 pm

Joe Krahn wrote:

> [..snip..] there is a big di

vantage of being able to cast pointers.

Do you mean there is a big di

vantage of *not* being able to case pointers?

cheers,

paulv

--
Paul van Delst Ride lots.
CIMSS @ NOAA/NCEP/EMC Eddy Merckx
Ph: (301)763-8000 x7748
Fax:(301)763-8545

Terence

2006-07-21, 7:01 pm

Brooks Moses raised the point of assignable arrays being one of the
advantages of newer compilers.

But "back when" (around 1964 I think), the BMD statistical software
from UCLA in California showed the trick of how you could read your
working parameters in a start module, tthen carve up available named
spaces in (yes, multiple 64k limited) blocks of working memory, by
defining matrix start points and dimension numbers, (then adding the
size to the last pointer and repeating fo rth next array); then all
subprograms in the system were then called as
CALL BMD4F( space(my3Da), ixdim,iydim,izdim,
proj(my2Db),jxdim,jydim,,,,,,,)

In essence it did what SHAPE does and it was effective.

This achieved what was needed for a whole large suite of scientific
programs.
It worked. it was self-documenting by the block names and variable
names.

And this was Fortran IV. I had a 1600 bpi tape of this system source
code, but alas, the earth's magnetic field has since made it pretty
much unreadable now. ("Tomorrow I must get that on floppies.."!).
Remember the RS232C tape drives for PC's???).
What will I do with all this blank punch cards?

Terence Wright

Walter Spector

2006-07-22, 3:59 am

Terence wrote:
> ...
> However I still prefer the computed GOTO over the CASE alternative,
> even though the variable had to be monotonically increasing for the
> GOTO version.

Fortran-90s CASE is much more flexible and readable than computed GOTO.
For example you can use ranges. And character strings...

> And I still wonder if anything important has been gained
> with F90 beyond the valuable full checking of variables between
> subprograms. Way, way back, PL/1 introduced matrix arithmetic which was
> a long time coming with Fortran.

If you had asked me 15 years ago what the most important things were
in Fortran-90, the array syntax probably would have headed the list.
Now, with 15 years of F90/95 experience under my belt, many other
things seem far more important.

> My point is: is Fortran programming now becoming more difficult and
> exacting?

I think it is 'less difficult' to do many things. But it certainly is
becoming more exacting. And I think it is a Good Thing. It is better
to discover bugs early - during compilation, than have to chase them at
run-time.

> Were the advances beyond F77 more academic than truly advantageous?

Absolutely advantageous. The 'academics' seem to teach their students
that Fortran ended in 1977. Most of the rest of us know better.

Dynamic memory management improves almost every program. I don't understand
how anyone can defend the 'recompile when my problem size changes' style
of programming. In F-77, one had no choice. (And yes I am fully aware
of how many apps 'hacked' in dynamic memory in the olden days. I was quite
guilty of it myself. But such techniques were very error-prone and non-
portable.)

Modules are a huge advance, once you get the hang of 'em. Again, I would
have a hard time not wanting them. F77 had little name-space management,
no *Standard* way to ensure arguments were passed consistently and global
variables were defined consistently. COMMON blocks are very restrictive.
All in all, very error-prone. Yes there were sympomatic fixes to 'work
around' some ofthese problems. But F90 modules fix the problems properly.

Derived types? Again, very handy and I use them a lot. Proper use of
them simplifies a lot of code, as you can carry a lot of information about
an object around in a program without much hassle.

Long variable names - Yes, most F77 compilers were extended. But the fact
remains that they were NON-Standard. And there were F77 compilers that did
not support long variable names (or were only slightly extended to 7 or 8
characters. Still too short.)

The new argument passing mechanisms? Again, they allow the ability to write
much more concise and error-free code. You don't need a bunch of extra
arguments to pass array dimensions around. Just pass the array and use
SIZE/LBOUND/UBOUND when you need them... INTENT allows the compiler to find
a lot of problems at compile time. OPTIONAL arguments are very handy
too.

Recursion? I use it when needs arise.

CONTAINed procedures? I use them in almost every program I write.

Free form source? Again, just about every program I write. No more worries
about going across column 72. Or wondering how many columns a tab character
is considered as using.

I've made my peace with Fortran-90 POINTERs. And use them when I have to.
(Though Cray-style pointers still have their uses...)

Oh yeah, and then there is array syntax. Which I do use. Just not as much as
I thought I would 15 years ago...

These are all solid advances to the programmer. If Fortran-90 hadn't come out
when it did, I am certain that I would be programming almost entirely in C++
these days. (Am sliding in that direction anyway, but it is a matter of degree...)

BTW, do you have any early IBM Fortran material? I know that the Computer
History Museum is looking for a copy of the original Fortran compiler for
the 704. (I think they managed to find Fortran-II.)

Walt

Terence

2006-07-22, 7:59 am

Sorry Walter,
> ... do you have any early IBM Fortran material? I know that the Computer
> History Museum is looking for a copy of the original Fortran compiler for
> the 704.

I had to move house and continents twice, and freight and space was
expensive. Most historic IBM stuff (1620, 1401, 1410, 704) went in the
1964 move, except for one internal paper of mine, and notes on the
Fortran team members. Everything else (IBM 709, 7074, 360, 1130, HP
mini) except some B22 manuals went in a 2001 move to Sydney, when I
also junked a lot of working hardware now worth money.

But some post-1964 materials like the later IBM PC AT complete hardware
and software set and Fortran compilers etc., may be in our programming
offices in Caracas. I have with me much PL/1 and Fortran sources of
interesting and unusual algorithms. I still have my own October 1939
"Electrical and Radio Notes for Wireless Operators" and my un-cashed
1940 saving certificates....

Terence Wright

glen herrmannsfeldt

2006-07-22, 7:00 pm

Walter Spector wrote:

(snip)

> Dynamic memory management improves almost every program. I don't understand
> how anyone can defend the 'recompile when my problem size changes' style
> of programming. In F-77, one had no choice. (And yes I am fully aware
> of how many apps 'hacked' in dynamic memory in the olden days. I was quite
> guilty of it myself. But such techniques were very error-prone and non-
> portable.)

Error prone I agree, but if done right they should be portable.

The usual one involves a large array which is then divided up as
appropriate. Fortran allowed, and still allows, passing an array
element to a subprogram and referencing array elements between that
element and the end of the array.

A large fraction of programs needing dynamic memory can calculate the
appropriate sizes near the beginning and use those sizes throughout.
(Many are adopted from programs using fixed size arrays, and may not
have been written that way if dynamic memory was available.)

The size of the large array must be set in advance, but once set the
memory can be divided up as needed.

-- glen

Brooks Moses

2006-07-22, 7:00 pm

glen herrmannsfeldt wrote:
> Walter Spector wrote:
>
> Error prone I agree, but if done right they should be portable.
>
> The usual one involves a large array which is then divided up as
> appropriate. Fortran allowed, and still allows, passing an array
> element to a subprogram and referencing array elements between that
> element and the end of the array.
>
> A large fraction of programs needing dynamic memory can calculate the
> appropriate sizes near the beginning and use those sizes throughout.
> (Many are adopted from programs using fixed size arrays, and may not
> have been written that way if dynamic memory was available.)
>
> The size of the large array must be set in advance, but once set the
> memory can be divided up as needed.

I would make the objection that this doesn't really help the situation,
given that the problem is often (or, in my case, always) that all of the
arrays are sized in roughly-known proportion to each other, and one
would prefer to not have the program take up excess memory when the
overall size is "small", but still be able to run when it's "large".
Dividing up a large array is mostly helpful when there are both large
and small arrays at the same time, and one doesn't know which is which.

On the other hand, given that at least some systems seem to only
allocate the memory for an array if it's actually used, it may well be
that one can just set the size of the large array to "very large" and
still get a relatively small actual memory usage when one doesn't use
much of the large array. So, in that sense, the program itself is
portable, but it may not achieve the desired goal on all systems.

I have done things like this, though -- not that I needed the dynamic
sizing, so much as needing the capability to set up an arbitrary number
of arrays of different sizes. (This was a multigrid method, with a 2x2
array, a 4x4 array, an 8x8 array, a 16x16 array, and so on up to some
NxN, and I needed to be able to refer to the arrays by index number.)
Getting that to all work right was definitely something that felt
error-prone. Declaring a derived type with an allocatable array in it,
and then having an array of objects of this type, is much cleaner!

- Brooks

--
The "bmoses-nospam" address is valid; no unmunging needed.

glen herrmannsfeldt

2006-07-23, 3:59 am

Brooks Moses wrote:
> glen herrmannsfeldt wrote:
(snip regarding using one large array for dynamic memory
in Fortran 77)

[color=darkred]
> I would make the objection that this doesn't really help the situation,
> given that the problem is often (or, in my case, always) that all of the
> arrays are sized in roughly-known proportion to each other, and one
> would prefer to not have the program take up excess memory when the
> overall size is "small", but still be able to run when it's "large".
> Dividing up a large array is mostly helpful when there are both large
> and small arrays at the same time, and one doesn't know which is which.

Yes, some do that.

> On the other hand, given that at least some systems seem to only
> allocate the memory for an array if it's actually used, it may well be
> that one can just set the size of the large array to "very large" and
> still get a relatively small actual memory usage when one doesn't use
> much of the large array. So, in that sense, the program itself is
> portable, but it may not achieve the desired goal on all systems.

For single task machines, which was pretty common when Fortran
was young, and also for machines running MS-DOS, it really didn't
matter how much you used, up to the maximum available.

For multitask real memory machine is did, but Fortran couldn't
do much about it.

But yes, for virtual memory machines, it is usual not to allocate
even swap space for the entire memory requested, though many early
virtual memory systems did allocate swap space for the whole program.

> I have done things like this, though -- not that I needed the dynamic
> sizing, so much as needing the capability to set up an arbitrary number
> of arrays of different sizes. (This was a multigrid method, with a 2x2
> array, a 4x4 array, an 8x8 array, a 16x16 array, and so on up to some
> NxN, and I needed to be able to refer to the arrays by index number.)
> Getting that to all work right was definitely something that felt
> error-prone. Declaring a derived type with an allocatable array in it,
> and then having an array of objects of this type, is much cleaner!

I wasn't arguing against error prone, or even ugly, but it can
be done portably.

-- glen

Walter Spector

2006-07-23, 6:59 pm

glen herrmannsfeldt wrote:
> ...
> The size of the large array must be set in advance, but once set the
> memory can be divided up as needed.

If you have to set a maximum size in advance, calling it "dynamic" is
questionable.

Many years ago, someone published a paper. I've forgotten the exact name,
something like "Real World Fortran Programming", that espoused such techniques.
IIRC, it went through a number of examples - overindexing blank common,
masking/shifting Hollerith fields, implementing structured forms using the
GO TO statements, and such. A lot of the stuff the textbooks failed to teach.

I used to have a copy of this paper, but lost track of it probably 25 years ago.
Does it ring any bells with any of the old timers?

A book that I DO still have is the classic "Fortran Techniques", by A. Colin Day
(1972, mine is the 1977 reprint). It is a fun little book. In it he describes a
lot of the same. But languages, compilers, and proper software engineering
have come a long ways since then. (Wow - I just checked Amazon, and it is still
in print! It is pretty obsolete WRT of Fortran-90 though.)

W.

John Harper

2006-07-23, 6:59 pm

In article <1153527636.388869.126280@b28g2000cwb.googlegroups.com>,
Terence <tbwright@cantv.net> wrote:
>
>What will I do with all this blank punch cards?

Off topic but you did ask for suggestions: my main use is to put them
under the necks of wine bottles in the cellar with the details written
on them, so I don't have to disturb the bottle itself when deciding
what to bring out for a dinner or party. I had a lot of pink, white,
yellow and green cards when this university got rid of its card reader;
they suit red and white wine, sherry and green ginger wine.

-- John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045

Jan Vorbrüggen

2006-07-24, 3:59 am

> Long variable names - Yes, most F77 compilers were extended. But the fact
> remains that they were NON-Standard. And there were F77 compilers that did
> not support long variable names (or were only slightly extended to 7 or 8
> characters. Still too short.)

Or even worse, that compiler that truncated names longer than six letters to
those six, without any warning or other message.

> I've made my peace with Fortran-90 POINTERs. And use them when I have to.
> (Though Cray-style pointers still have their uses...)

But only very, very rarely. Of course, it's much easier not to specify an
interface in sufficient detail that you don't need a Cray pointer.

> Oh yeah, and then there is array syntax. Which I do use. Just not as much as
> I thought I would 15 years ago...

Even the trivial uses of array syntay unclutter the code a lot, IMO - even if
it's just an initialization of an array or somesuch. And with those nice in-
trincics such as CSHIFT et al, you can write in one line correctly what takes
two dozen lines of code that takes several iterations to get right.

Jan

Jugoslav Dujic

2006-07-24, 7:59 am

Brooks Moses wrote:
| David Flower wrote:
|| The question that should have been asked is:
||
|| What is missing in F77 ?
||
|| and what was added in F90 included much that did not significantly
|| increase functionality (e.g. Free form source), and illustrated neglect
|| of the maxim 'If it ain't broke, don't fix it'.
|
| Have you ever owned a car where the tie rod ends were going bad, so that
| the steering had gotten terribly loose? Since it happens slowly, the
| owner of the car is usually unaware that they're turning the steering
| wheel this way and that to keep the car going straight, and have no
| problem with it, but anyone who's not used to it has a difficult time
| keeping the car on the road.
|
| Fixed-form source is a lot like that. From the perspective of most
| people who haven't been using it for several years, it's definitely broken.

I'll have to bookmark this post. Great analogy, Brooks.

--
Jugoslav
___________
www.xeffort.com

Please reply to the newsgroup.
You can find my real e-mail on my home page above.

glen herrmannsfeldt

2006-07-24, 7:59 am

Walter Spector wrote:
> glen herrmannsfeldt wrote:

[color=darkred]
> If you have to set a maximum size in advance, calling it "dynamic" is
> questionable.

In many cases it is different sizes within the program that matter, in
others it isn't. There is always a maximum somewhere, the size of the
machine (real addressing), the size of the swap disk (virtual
addressing), or even the address space size.

> Many years ago, someone published a paper. I've forgotten the exact name,
> something like "Real World Fortran Programming", that espoused such techniques.
> IIRC, it went through a number of examples - overindexing blank common,
> masking/shifting Hollerith fields, implementing structured forms using the
> GO TO statements, and such. A lot of the stuff the textbooks failed to teach.

Overindexing COMMON doesn't sound standard, but one can vary the size
without recompiling the whole program. In some cases, you recompiles
one routine with a COMMON statement to the appropriate size, and legally
references to the end of COMMON from other routines.

> I used to have a copy of this paper, but lost track of it probably 25 years ago.
> Does it ring any bells with any of the old timers?

> A book that I DO still have is the classic "Fortran Techniques", by A. Colin Day
> (1972, mine is the 1977 reprint). It is a fun little book. In it he describes a
> lot of the same. But languages, compilers, and proper software engineering
> have come a long ways since then. (Wow - I just checked Amazon, and it is still
> in print! It is pretty obsolete WRT of Fortran-90 though.)

There may still be enough people working on old code for it to be useful.

-- glen

Carlie J. Coats

2006-07-26, 7:01 pm

Brooks Moses wrote:

> [snip...]
> It might possibly be that,
> because the language is growing, reading other people's Fortran programs
> is becoming more difficult...

Or then again...

I notice that there seems to be at least one personality type that
thinks structure is good -- the more structure the better, whether
that structure is appropriate or not. [I think of a major meteorology
model where it is necessary to chase through 12 levels of subroutine
calls (two of which are indirect, calling a function argument passed
in) in order to understand how I/O works -- and for which the file
structure is hard-coded in this call hierarchy, rather than being
table-driven or something!]

Unfortunately, Fortran 90/95/03 gives this personality type more
rope with which to confuse the rest of us.

--

Carlie J. Coats, Jr. carlie.coats@baronams.com
Environmental Modeling Center carlie_coats@ncsu.edu
Baron Advanced Meteorological Systems, LLC.
920 Main Campus Drive, Suite 101
Raleigh, NC 27606 phone: (919)424-4444 / fax: (919)424-4401
"My opinions are my own, and I've got *lots* of them!"

Terence

2006-07-27, 7:00 pm

Glen Herrmannsfeldt mentioned:-
> Overindexing COMMON doesn't sound standard, but one can vary the size
> without recompiling the whole program. In some cases, you recompiles
> one routine with a COMMON statement to the appropriate size, and legally
> references to the end of COMMON from other routines.

I've said this elswhere, but the 1966 BMD statiistical program source
from UCLA in California used this technique for total portability.
You certainly didn't recompile anything once compiled and installed for
general use.

The only limitation then, was the possible size of named common in some
architectures (e.g. 64K in later AT-type PCs), but then you don't
really have any statistical measures if there are too many variables
(not too many cases - that's good); you just get just noise. So 2D and
3D array spaces usually were individually reasonable in requirements.

Then a first, common-to-all, sub-program asked questions about the
dimensions of the data arrays of the user, and then carved up the
defined named common blocks to provide the arrray shapes, and
initialised the indexes within these blocks, as values of variables
that all the other modules of the system could use.
All other subprograms were then passed these block-indexed addresses as
the array addresses to use.

So we hade a limited form of dynamic array assignment back then.

Since Fortran began, I've seen so MANY problems presented that
sometimes could be resolved by a different approach or a different
algorithm.
Some of the old tricks are useful and some old code is very readable.

Terence Wright

Gordon Sande

2006-07-27, 7:00 pm

On 2006-07-27 19:23:06 -0300, "Terence" <tbwright@cantv.net> said:

> Glen Herrmannsfeldt mentioned:-
>
> I've said this elswhere, but the 1966 BMD statiistical program source
> from UCLA in California used this technique for total portability.
> You certainly didn't recompile anything once compiled and installed for
> general use.
>
> The only limitation then, was the possible size of named common in some
> architectures (e.g. 64K in later AT-type PCs), but then you don't
> really have any statistical measures if there are too many variables
> (not too many cases - that's good); you just get just noise. So 2D and
> 3D array spaces usually were individually reasonable in requirements.
>
> Then a first, common-to-all, sub-program asked questions about the
> dimensions of the data arrays of the user, and then carved up the
> defined named common blocks to provide the arrray shapes, and
> initialised the indexes within these blocks, as values of variables
> that all the other modules of the system could use.
> All other subprograms were then passed these block-indexed addresses as
> the array addresses to use.
>
> So we hade a limited form of dynamic array assignment back then.
>
> Since Fortran began, I've seen so MANY problems presented that
> sometimes could be resolved by a different approach or a different
> algorithm.
> Some of the old tricks are useful and some old code is very readable.
>
> Terence Wright

There were also the small assembly programs that returned the lower
apparent subscript and upper apparent subscript (or something that
was technically equivalent like lower and length) of a region of
memory that was obtained dynamically. Other than that one hack it was
all relatively transparent and even allowed a fall back implementation
that was pure Fortran.

There were also the codes that used the linkage editor to change the
size of the allocated commons and the block data which indicated the
sizes.

Intersting history that is now no longer needed.

robin

2006-07-27, 7:00 pm

David Flower wrote in message <1153487625.361648.206140@i42g2000cwa.googlegroups.com>...

>I suspect that part of the problem is that the wrong question was asked
>about what was wanted in F90.
>
>The question that should have been asked is:
>
> What is missing in F77 ?
>
>and what was added in F90 included much that did not significantly
>increase functionality (e.g. Free form source),

Free form source added significant funxtionality:
1. The convenience of not using a rigid error-prone format,
where thebody of source lines coul;d not exceed 66 characters;
2. ability to detect silly errors including missed periods,
missed letters, and so on.

> and illustrated neglect
>of the maxim 'If it ain't broke, don't fix it'.

Fixed source form was broke, and it needed fixing.

robin

2006-07-28, 8:01 am

Walter Spector wrote in message <44C1CEEB.1A437F63@earthlink.net>...
>Terence wrote:

That was in 1965.
[color=darkred]
> which was a long time coming with Fortran.
>
>If you had asked me 15 years ago what the most important things were
>in Fortran-90, the array syntax probably would have headed the list.
>Now, with 15 years of F90/95 experience under my belt, many other
>things seem far more important.
>
>
>Absolutely advantageous. The 'academics' seem to teach their students
>that Fortran ended in 1977.

That is simply not true.

> Most of the rest of us know better.
>
>Dynamic memory management improves almost every program. I don't understand
>how anyone can defend the 'recompile when my problem size changes' style
>of programming. In F-77, one had no choice. (And yes I am fully aware
>of how many apps 'hacked' in dynamic memory in the olden days. I was quite
>guilty of it myself. But such techniques were very error-prone and non-
>portable.)

Adjustable dimensions was portable.

At least procedures had the semblance of working on
dynamic array arguments.

Sponsored Links