.NH
CONCLUSIONS
.PP
Ratfor
demonstrates that with modest effort
it is possible to convert Fortran
from a bad language into quite a good one.
A preprocessor 
is clearly a useful way to extend or ameliorate
the facilities of a base language.
.PP
When designing a language,
it is important to concentrate on
the essential requirement of providing
the user with the best language possible
for a given effort.
One must avoid throwing in
``features'' _
things which the user may trivially construct within the existing
framework.
.PP
One must also avoid getting sidetracked on irrelevancies.
For instance it seems pointless for
Ratfor
to prepare a neatly formatted
listing of either its input or its output.
The user is presumably capable of the self-discipline required
to prepare neat input
that reflects his thoughts.
It is much more important that the language provide free-form input
so he
.ul
can
format it neatly.
No one should read the output anyway
except in the most dire circumstances.
.SH
Acknowledgements
.PP
C. A. R. Hoare
once said that
``One thing [the language designer] should not do
is to include untried ideas of his own.''
Ratfor
follows this precept very closely _
everything in it has been stolen from someone else.
Most of the control flow structures
are taken directly from the language C[4]
developed by Dennis Ritchie;
the comment and continuation
conventions are adapted from Altran[10].
.PP
I am grateful to Stuart Feldman,
whose patient simulation of an innocent user
during the early days of Ratfor
led to several design improvements
and the eradication of bugs.
He also translated the C parse-tables
and
.UC YACC 
parser
into Fortran for the
first
Ratfor
version of
Ratfor.
