xref: /original-bsd/old/ratfor/USD.doc/m1 (revision e21485a6)
@(#)m1 6.1 (Berkeley) 04/29/86

.nr PS 9 .nr VS 11
INTRODUCTION

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.

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 C IF forces the user into at least two statement numbers and two (implied) C GOTO 's; it leads to unintelligible code, and is eschewed by good programmers. The Logical C IF is better, in that the test part can be stated clearly, but hopelessly restrictive because the statement that follows the C IF can only be one Fortran statement (with some .ul further restrictions!). And of course there can be no C ELSE part to a Fortran C IF : there is no way to specify an alternative action if the C IF is not satisfied.

The Fortran C 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 And of course the C DO is useless if one's problem doesn't map into an arithmetic progression.

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.

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.)