Hi,

Does anyone have Fortran experience and the energy to answer a few questions?

I have a project comming up to convert a Fortran program into something else and have started preparing by trying to understand the Fortran (never dealt with it before), and refactoring the code into something tidier (it seems messier than it should be...).

With a little Googling and general experience it doesn't seem too bad, but I wanted to confirm a few things (some of which is out of curiosity rather than need).

(The only "odd" things I've found are a few implied iterators within READ and WRITE statements.)

For starters, my first few questions are:

1. Does it matter where in a subroutine the FORMAT statements appear e.g. before or after the READ or WRITE that uses it? e.g. Can they all be put at the start of the sub? What's "normal"?

2. Is there some history to the introduction of IF THEN / ELSE / END IF and DO / END DO? The code I'm looking at was an awful mess of GO TO and labels, but I found the nicer structures in the first Fortran reference I googled up.

3. Some of the ugly looping with GO TO I've turned into DO / END DO.
I made some do-until type loops into:
DO WHILE 1 .EQ 1
...
...
IF something EXIT
END DO

Is there a better way? (An actual DO ... UNTIL?)

4. Are subroutine arguments passed by reference or by value?

Thanks for any advice.

Cheers,

__________________
Measure once. Cut twice. Power tools are fun.

It's standard practice to put the FORMAT statements at the end of the subroutine. FORTAN passes by *reference* mostly. There's complications with some things, but simple variables are passed by reference.

FORTRAN has been around for a long time, see the history here:

http://en.wikipedia.org/wiki/FORTRAN

FORTAN 66 (1966) was the first standard, followed by FORTRAN 77, and finally, FORTRAN 90 and on. Structured control statements were added through those iterations, usually first as extensions to the standard by specific compiler vendors, which were incorporated into the later standards.

I have Intel's Visual FORTRAN, which is where DEC's x86 compiler ended up, and (IMHO of course) is the best current Wintel FORTRAN compiler. It meets all the standards, has numerous extensions and can take anything from FORTRAN 77 on up. It's no small feat to handle the new standard and yet still do the old.

FORTRAN is still king for numerical work, don't let anyone argue you otherwise. The built in things you can do with arrays are quite impressive.

-Richard

I've had lots with DecFortran (a variation of Fortran77). But; it's been such a long time, that the details are mostly lost.
I can do that with any language if I wanted to. Luckily, I never wanted to.
Memory hazy...
Yes; absolutely. Any of the older languages that didn't have a robust blocking structure has gone through growing pains of adopting this kind of structure. If the language has a GOTO, then it's gone through this metamorphisis.
I would think that has more to do with both the age of the program, and the age of the programmer. I would say that there was a very common use of GOTO into the 80's, and that depended entirely on the experience of the programmer and experience in different languages of the programmer.
I'm sure there are more details that cause it to be ugly. Best if you did the "while not something" with branches of "if something" within the loop if you don't have an UNTIL type of loop.
Do you have a reference source of the flavor of language you have? That would be my best suggestion... I do recall some REPEAT...UNTIL, but I may be confusing it with VaxBasic.
Again; this depends on your version. In the Vax world this varied by variable type, and was more dependent on architecture than by language so that various language calls can be incorporated.
Also; the older Fortrans were not "stacked" calls (static variables), So any recursive-like calls would re-use the same memory locations instead of each occurance being isolated.

I know I haven't helped that much, but I thought a little insight was in order.

__________________
Numbers are not case sensitive. (me)

Hi,

Thanks to both publius and NEOWatcher.

I think my next step is to very carefully look at the subroutines to see if modification of the passed-in arguments is "supposed" to have effects (in this program) back in the caller of the sub.

Cheers,

__________________
Measure once. Cut twice. Power tools are fun.

Lol, that brings back memories! Last fortran I coded looked like
Do 100, i=1,31,3
if (i-j) 10,20,30
...
100 Continue

Hated goto's especially the computed goto, so never used them if possible, and when not, I always went to a contiue statement for an error exit.

No matter how they improve a language, someone always finds a way to write ugly, inefficient code!

__________________
Sue ikki
mi hatenu yume no
hotsure kana---Choko
(This final scene, I
I will not see to the end.
My dream is fraying.)

Real programmers can write FORTRAN code in any language!

Fred the Real Programmer

__________________
"For shame, gentlemen, pack your evidence a little better against another time."
-- John Dryden, "The Vindication of The Duke of Guise" 1684

pzkpfw, what you said.

Seriously, you pretty much summarized all the rules of the road my Fortran (WATFIV and FORTRAN77) instructor drummed into our heads.

Go with what you wrote in the first post. And yes, it's best to put formatting statements at the top of the sections they affect, if for no other reason that it's easier on the programmer's eyes. When it compiles, it won't matter.

GO TOs still have their purpose, particularly in branching out conditions which simply don't warrant going through the next section (such as if a particular condition is already met, as in a deviation is below the criteria specified). But they're horrible for controlling iterative functions, as you're already surmised.

__________________
I am Mugs, of the Alien clan of Usa, Nordamerica, a Terran, of Sol. A human.

Whoever says "perception is reality" is daft. It's merely an abstraction, and often not a very good one.