.nr PS 9
.nr VS 11
.if t .2C
.if n .ls 2
.NH
INTRODUCTION
.PP
Most programmers will agree that Fortran is
an unpleasant language to program in,
yet there are many occasions when they are forced to use it.
For example, Fortran is often the only language
thoroughly supported on the local computer.
Indeed, it is the closest thing to a universal programming language
currently available:
with care it is possible to write large, truly portable
Fortran programs[1].
Finally, Fortran is often the most ``efficient'' language
available, particularly for programs requiring much computation.
.PP
But Fortran 
.ul
is
unpleasant.
Perhaps the worst deficiency is in
the control flow
statements
_ conditional branches and loops _
which express the logic of the program.
The conditional statements in Fortran are primitive.
The Arithmetic 
.UC IF
forces the user into at least two statement numbers and
two (implied) 
.UC GOTO 's;
it leads to unintelligible code, and is eschewed by good programmers.
The Logical
.UC IF
is better, in that the test part can be stated clearly,
but hopelessly restrictive because the statement
that follows the
.UC IF
can only be one Fortran statement
(with some
.ul
further
restrictions!).
And of course there can be no
.UC ELSE
part to a Fortran
.UC IF :
there is no way to specify an alternative action if the
.UC IF
is not satisfied.
.PP
The Fortran
.UC DO
restricts the user to going forward in an arithmetic progression.
It is fine for ``1 to N in steps of 1 (or 2 or ...)'',
but there is no direct way to go backwards,
or even (in ANSI Fortran[2]) to go from 1 to
.if n N-1.
.if t N\(mi1.
And of course the
.UC DO
is useless if one's problem doesn't map into an arithmetic progression.
.PP
The result of these failings is that Fortran programs
must be written with numerous labels and branches.
The resulting code is
particularly difficult to read and understand,
and thus hard to debug and modify.
.PP
When one is faced with an unpleasant language,
a useful technique is to define
a new language that overcomes the deficiencies,
and to translate it into the unpleasant one
with a preprocessor.
This is the approach taken with 
Ratfor.
(The preprocessor idea is of course not new,
and preprocessors for Fortran are especially popular
today.
A recent listing [3] of preprocessors 
shows more than 50, of which at least half a dozen are widely available.)
