m2

unix v7是最后一个广泛发布的研究型UNIX版本

.NH
LANGUAGE DESCRIPTION
.SH
Design
.PP
Ratfor
attempts to retain the merits of Fortran
(universality, portability, efficiency)
while hiding the worst Fortran inadequacies.
The language
.ul
is
Fortran except for two aspects.
First,
since control flow is central to any program,
regardless of the specific application,
the primary task of
Ratfor
is to conceal this part of Fortran from the user,
by providing decent control flow structures.
These structures are sufficient and comfortable
for structured programming in the narrow sense of programming without
.UC GOTO 's.
Second, since the preprocessor must examine an entire program
to translate the control structure,
it is possible at the same time to clean up many of the
``cosmetic'' deficiencies of Fortran,
and thus provide a language which is easier
and more pleasant to read and write.
.PP
Beyond these two aspects _ control flow and cosmetics _
Ratfor
does nothing about the host of other weaknesses of Fortran.
Although it would be straightforward to extend 
it
to provide
character strings,
for example,
they are not needed by everyone,
and of course
the preprocessor would be harder to implement.
Throughout, the design principle which has determined
what should be in
Ratfor
and what should not has
been
.ul
Ratfor
.ul
doesn't know any Fortran.
Any language feature which would require that
Ratfor
really understand Fortran has been omitted.
We will return to this point in the section
on implementation.
.PP
Even within the confines of control flow and cosmetics,
we have attempted to be selective
in what features to provide.
The intent has been to provide a small set of the most useful
constructs,
rather than to throw in everything that has ever been thought useful
by someone.
.PP
The rest of this section contains an informal description
of the
Ratfor
language.
The control flow aspects will be
quite familiar to readers used to languages like
Algol, PL/I, Pascal, etc.,
and the cosmetic changes are equally straightforward.
We shall concentrate on 
showing what the language looks like.
.SH
Statement Grouping
.PP
Fortran provides no way to group statements together,
short of making them into a subroutine.
The standard construction
``if a condition is true,
do this group of things,''
for example,
.P1
if (x > 100)
	{ call error("x>100"); err = 1; return }
.P2
cannot be written directly in Fortran.
Instead
a programmer is forced to translate this relatively
clear thought into murky Fortran,
by stating the negative condition
and branching around the group of statements:
.P1
	if (x .le. 100) goto 10
		call error(5hx>100)
		err = 1
		return
10	...
.P2
When the program doesn't work,
or when it must be modified,
this must be translated back into
a clearer form before one can be sure what it does.
.PP
Ratfor
eliminates this error-prone and confusing back-and-forth translation;
the first form 
.ul
is
the way the computation is written in 
Ratfor.
A group of statements can be treated as a unit
by enclosing them in the braces { and }.
This is true throughout the language:
wherever a single 
Ratfor
statement can be used,
there can be several enclosed in braces.
(Braces seem clearer and less obtrusive than
.UL begin
and
.UL end 
or
.UL do
and
.UL end ,
and of course 
.UL do
and
.UL end
already have Fortran meanings.)
.PP
Cosmetics
contribute to the readability of code,
and thus to its understandability.
The character ``>'' is clearer than
.UC ``.GT.'' ,
so
Ratfor
translates it appropriately,
along with several other similar shorthands.
Although many Fortran compilers permit character strings in quotes
(like
.UL """x>100""" ),
quotes are
not allowed in 
.UC ANSI
Fortran,
so 
Ratfor
converts it into the right number of
.UL H 's:
computers count better than people do.
.PP
Ratfor
is a free-form language:
statements may appear anywhere on a line,
and several may appear on one line
if they are separated by semicolons.
The example above could also be written as
.P1
if (x > 100) {
	call error("x>100")
	err = 1
	return
}
.P2
In this case, no semicolon is needed at the end of each line because
Ratfor
assumes there is one statement per line
unless told otherwise.
.PP
Of course,
if the statement that follows the
.UL if
is a single statement
(Ratfor
or otherwise),
no braces are needed:
.P1
if (y <= 0.0 & z <= 0.0)
	write(6, 20) y, z
.P2
No continuation need be indicated 
because the statement is clearly not finished on the first line.
In general
Ratfor
continues lines when it seems obvious that they are not yet done.
(The continuation convention is discussed in detail later.)
.PP
Although a free-form language permits wide latitude in formatting styles,
it is wise to pick one that is readable, then stick to it.
In particular, proper indentation is vital,
to make the logical structure of the program obvious to the reader.
.sp
.SH
The ``else'' Clause
.PP
Ratfor
provides an
.UL "else"
statement to handle the construction
``if a condition is true,
do 
this
thing,
.ul
otherwise
do that thing.''
.P1
if (a <= b)
	{ sw = 0; write(6, 1) a, b }
else
	{ sw = 1; write(6, 1) b, a }
.P2
This writes out the smaller of
.UL a
and
.UL b ,
then the larger, and sets
.UL sw
appropriately.
.PP
The Fortran equivalent of this code is circuitous indeed:
.P1
	if (a .gt. b) goto 10
		sw = 0
		write(6, 1) a, b
		goto 20
10	sw = 1
	write(6, 1) b, a
20	...
.P2
This is a mechanical translation;
shorter forms exist, 
as they do for many similar situations.
But all translations suffer from the same problem:
since they are translations,
they are less clear and understandable than code
that is not a translation.
To understand the Fortran version,
one must scan the entire program to make
sure that no other statement branches
to statements 10 or 20
before one knows that indeed this is an 
.UL if-else
construction.
With the
Ratfor
version,
there is no question about how one gets to the parts of the statement.
The
.UL if-else
is a single unit,
which can be read, understood, and ignored if not relevant.
The program says what it means.
.PP
As before, if the statement following an
.UL if
or an
.UL else
is a single statement, no braces are needed:
.P1
if (a <= b)
	sw = 0
else
	sw = 1
.P2
.PP
The syntax of the
.UL if
statement is
.P1
if (\fIlegal Fortran condition\fP)
	\fIRatfor statement\fP
else
	\fIRatfor statement\fP
.P2
where the 
.UL else
part is optional.
The
.ul
legal Fortran condition
is
anything that can legally go into a Fortran Logical
.UC IF .
Ratfor
does not check this clause,
since it does not know enough Fortran
to know what is permitted.
The
.ul
Ratfor
.ul
statement
is any Ratfor or Fortran statement, or any collection of them
in braces.
.SH
Nested if's
.PP
Since the statement that follows an
.UL if
or 
an
.UL else
can be any Ratfor statement, this leads immediately
to the possibility of another
.UL if
or
.UL else .
As a useful example, consider this problem:
the variable
.UL f
is to be set to
\-1 if
.UL x
is less than zero,
to
+1
if
.UL x
is greater than 100,
and to 0 otherwise.
Then in Ratfor, we write
.P1
if (x < 0)
	f = -1
else if (x > 100)
	f = +1
else
	f = 0
.P2
Here the statement after the first
.UL else
is another
.UL if-else .
Logically it is just a single statement,
although it is rather complicated.
.PP
This code says what it means.
Any version written in straight Fortran
will necessarily be indirect
because Fortran does not let you say what you mean.
And as always, clever shortcuts may turn out
to be too clever to understand a year from now.
.PP
Following an
.UL else
with an
.UL if
is one way to write a multi-way branch in Ratfor.
In general the structure
.P1
if (...)
	- - -
else if (...)
	- - -
else if (...)
	- - -
 ...
else
	- - -
.P2
provides a way to specify the choice of exactly one of several alternatives.
(Ratfor also provides a
.UL switch
statement which does the same job
in certain special cases;
in more general situations, we have to make do
with spare parts.)
The tests are laid out in sequence, and each one
is followed by the code associated with it.
Read down the list
of decisions until one is found that is satisfied.
The code associated with this condition is executed,
and then the entire structure is finished.
The trailing
.UL else
part handles the ``default'' case,
where none of the other conditions apply.
If there is no default action, this final
.UL else
part
is omitted:
.P1
if (x < 0)
	x = 0
else if (x > 100)
	x = 100
.P2
.SH
if-else ambiguity
.PP
There is one thing to notice about complicated structures
involving nested
.UL if 's
and
.UL else 's.
Consider
.P1
if (x > 0)
	if (y > 0)
		write(6, 1) x, y
	else
		write(6, 2) y
.P2
There are two
.UL if 's
and
only one
.UL else .
Which
.UL if
does the
.UL else
go with?
.PP
This is a genuine ambiguity in Ratfor, as it is in many other programming
languages.
The ambiguity is resolved in Ratfor
(as elsewhere) by saying that in such cases the
.UL else
goes with the closest previous
.UL else 'ed un-
.UL if .
Thus in this case, the
.UL else
goes with the inner
.UL if ,
as we have indicated by the indentation.
.PP
It is a wise practice to resolve such cases by explicit braces,
just to make your intent clear.
In the case above, we would write
.P1
if (x > 0) {
	if (y > 0)
		write(6, 1) x, y
	else
		write(6, 2) y
}
.P2
which does not change the meaning, but leaves
no doubt in the reader's mind.
If we want the other association, we
.ul
must
write
.P1
if (x > 0) {
	if (y > 0)
		write(6, 1) x, y
}
else
	write(6, 2) y
.P2
.SH
The ``switch'' Statement
.PP
The
.UL switch
statement
provides a clean way to express multi-way branches
which branch on the value of some integer-valued expression.
The syntax is
.P1
\f3switch (\fIexpression\|\f3) {

	case \fIexpr1\f3 :
		\f2statements\f3
	case \fIexpr2, expr3\f3 :
		\f2statements\f3
	...
	default:
		\f2statements\f3
}
.P2
.PP
Each
.UL case
is followed by a
list of comma-separated integer expressions.
The
.ul
expression
inside
.UL switch
is compared against the case expressions
.ul
expr1,
.ul
expr2, 
and so on in turn
until one matches,
at which time the statements following that
.UL case
are executed.
If no cases match
.ul
expression,
and there is a
.UL default 
section,
the statements with it are done;
if there is no
.UL default,
nothing is done.
In all situations,
as soon as some block of statements is executed,
the entire
.UL switch
is exited immediately.
(Readers familiar with C[4] should beware that this
behavior is not the same as the C
.UL switch .)
.SH
The ``do'' Statement
.PP
The
.UL do
statement in
Ratfor
is quite similar to the
.UC DO
statement in Fortran,
except that it uses no statement number.
The statement number, after all, serves only to mark the end
of the
.UC DO ,
and this can be done just as easily with braces.
Thus
.P1
	do i = 1, n {
		x(i) = 0.0
		y(i) = 0.0
		z(i) = 0.0
	}
.P2
is the same as
.P1
	do 10 i = 1, n
		x(i) = 0.0
		y(i) = 0.0
		z(i) = 0.0
10	continue
.P2
The syntax is:
.P1
do \fIlegal\(hyFortran\(hyDO\(hytext\fP
	\fIRatfor statement\fP
.P2
The part that follows 
the keyword
.UL do
has to be something that can legally go into a Fortran
.UC DO
statement.
Thus if a local version of Fortran allows
.UC DO
limits to be expressions
(which is not currently permitted in
.UC ANSI
Fortran),
they can be used in a
Ratfor
.UL do.
.PP
The
.ul
Ratfor statement
part will often be enclosed in braces, but
as with the
.UL if ,
a single statement need not have braces around it.
This code sets an array to zero:
.P1
do i = 1, n
	x(i) = 0.0
.P2
Slightly more complicated,
.P1
do i = 1, n
	do j = 1, n
		m(i, j) = 0
.P2
sets the entire array
.UL m
to zero, and
.P1
do i = 1, n
	do j = 1, n
		if (i < j)
			m(i, j) = -1
		else if (i == j)
			m(i, j) = 0
		else
			m(i, j) = +1
.P2
sets the upper triangle of
.UL m
to \-1, the diagonal to zero, and the lower triangle to +1.
(The operator == is ``equals'', that is, ``.EQ.''.)
In each case, the statement that follows the
.UL do
is logically a
.ul
single
statement, even though complicated,
and thus needs no braces.
.sp
.SH
``break'' and ``next''
.PP
Ratfor
provides a statement for leaving a loop early,
and one for beginning the next iteration.
.UL "break"
causes an immediate exit from the
.UL do ;
in effect it is a branch to the statement
.ul
after
the
.UL do .
.UL next
is a branch to the bottom of the loop,
so it causes the next iteration to be done.
For example, this code skips over negative values in an array:
.P1
do i = 1, n {
	if (x(i) < 0.0)
		next
	\fIprocess positive element\fP
}
.P2
.UL break
and
.UL next
also work in the other Ratfor looping constructions
that we will talk about in the next few sections.
.PP
.UL break
and
.UL next
can be followed by an integer to indicate breaking or iterating
that level of enclosing loop; thus
.P1
break 2
.P2
exits from two levels of enclosing loops,
and
.UL break\ 1
is equivalent to
.UL break .
.UL next\ 2
iterates the second enclosing loop.
(Realistically, 
multi-level
.UL break 's
and
.UL next 's
are
not likely to be much used
because they lead to code that is hard to understand
and somewhat risky to change.)
.sp
.SH
The ``while'' Statement
.PP
One of the problems with the Fortran
.UC DO
statement
is that it generally insists upon being done once,
regardless of its limits.
If a loop begins
.P1
DO I = 2, 1
.P2
this will typically be done once with
.UL I
set to 2,
even though common sense would suggest that perhaps it shouldn't be.
Of course a
Ratfor
.UL do
can easily be preceded by a test
.P1