m2

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

if (j <= k)
	do i = j, k  {
		_ _ _
	}
.P2
but this has to be a conscious act,
and is often overlooked by programmers.
.PP
A more serious problem with the
.UC DO
statement
is that it encourages that a program be written
in terms of an arithmetic progression
with small positive steps,
even though that may not be the best way to write it.
If code has to be contorted to fit the requirements
imposed by the Fortran
.UC DO ,
it is that much harder to write and understand.
.PP
To overcome these difficulties,
Ratfor
provides a
.UL while
statement,
which is simply a loop:
``while some condition is true,
repeat this group of statements''.
It has
no preconceptions about why one is looping.
For example, this routine to compute sin(x)
by the Maclaurin series
combines two termination criteria.
.P1 1
.ta .3i .6i .9i 1.2i 1.5i 1.8i
real function sin(x, e)
	# returns sin(x) to accuracy e, by
	# sin(x) = x - x**3/3! + x**5/5! - ...

	sin = x
	term = x

	i = 3
	while (abs(term)>e & i<100) {
		term = -term * x**2 / float(i*(i-1))
		sin = sin + term
		i = i + 2
	}

	return
	end
.P2
.PP
Notice that
if the routine is entered with
.UL term
already smaller than
.UL e ,
the 
loop will be done
.ul
zero times,
that is, no attempt will be made to compute
.UL x**3
and thus a potential underflow is avoided.
Since the test is made at the top of a
.UL while
loop
instead of the bottom,
a special case disappears _
the code works at one of its boundaries.
(The test
.UL i<100
is the other boundary _
making sure the routine stops after
some maximum number of iterations.)
.PP
As an aside, a sharp character ``#'' in a line
marks the beginning of a comment;
the rest of the line is comment.
Comments and code can co-exist on the same line _
one can make marginal remarks,
which is not possible with Fortran's ``C in column 1'' convention.
Blank lines are also permitted anywhere
(they are not in Fortran);
they should be used to emphasize the natural divisions
of a program.
.PP
The syntax of the 
.UL while
statement is
.P1
while (\fIlegal Fortran condition\fP)
	\fIRatfor statement\fP
.P2
As with the
.UL if ,
.ul
legal Fortran condition
is something that can go into
a Fortran Logical
.UC IF ,
and
.ul
Ratfor statement
is a single statement,
which may be multiple statements in braces.
.PP
The
.UL while
encourages a style of coding not normally
practiced by Fortran programmers.
For example, suppose
.UL nextch
is a function which returns the next input character
both as a function value and in its argument.
Then a loop to find the first non-blank character is just
.P1
while (nextch(ich) == iblank)
	;
.P2
A semicolon by itself is a null statement,
which is necessary here to mark the end of the
.UL while ;
if it were not present, the
.UL while
would control the next statement.
When the loop is broken, 
.UL ich
contains the first non-blank.
Of course the same code can be written in Fortran as
.P1 1
100	if (nextch(ich) .eq. iblank) goto 100
.P2
but many Fortran programmers (and a few compilers) believe this line is illegal.
The language at one's disposal
strongly influences how one thinks about a problem.
.sp
.SH
The ``for'' Statement
.PP
The
.UL for
statement
is another Ratfor loop, which
attempts to carry the separation of
loop-body from reason-for-looping
a step further
than the
.UL while.
A
.UL for
statement allows explicit initialization
and increment steps as part of the statement.
For example, 
a
.UC DO
loop is just
.P1
for (i = 1; i <= n; i = i + 1) ...
.P2
This is equivalent to
.P1
i = 1
while (i <= n) {
	...
	i = i + 1
}
.P2
The initialization and increment of
.UL i
have been moved into the
.UL for
statement,
making it easier to see at a glance
what controls the loop.
.PP
The
.UL for
and
.UL while
versions have the advantage that they will be done zero times
if
.UL n
is less than 1; this is not true of the
.UL do .
.PP
The loop of the sine routine in the previous section
can be re-written
with a
.UL for
as
.P1 3
for (i=3; abs(term) > e & i < 100; i=i+2) {
	term = -term * x**2 / float(i*(i-1))
	sin = sin + term
}
.P2
.PP
The syntax of the
.UL for
statement is
.P1
for ( \fIinit\fP ; \fIcondition\fP ; \fIincrement\fP )
	\fIRatfor statement\fP
.P2
.ul
init
is any single Fortran statement, which gets done once
before the loop begins.
.ul
increment
is any single Fortran statement,
which gets done at the end of each pass through the loop,
before the test.
.ul
condition
is again anything that is legal in a logical 
.UC IF.
Any of 
.ul
init,
.ul
condition,
and
.ul
increment
may be omitted,
although the semicolons
.ul
must
always be present.
A non-existent
.ul
condition
is treated as always true,
so
.UL "for(;;)"
is an indefinite repeat.
(But see the
.UL repeat-until
in the next section.)
.PP
The
.UL for
statement is particularly
useful for
backward loops, chaining along lists,
loops that might be done zero times,
and similar things which are hard to express with a 
.UC DO
statement,
and obscure to write out 
with
.UC IF 's
and
.UC GOTO 's.
For example,
here is a
backwards
.UC DO
loop
to find the last non-blank character on a card:
.P1
for (i = 80; i > 0; i = i - 1)
	if (card(i) != blank)
		break
.P2
(``!='' is the same as 
.UC ``.NE.'' ).
The code scans the columns from 80 through to 1.
If a non-blank is found, the loop
is immediately broken.
.UL break \& (
and
.UL next
work in
.UL for 's
and
.UL while  's
just as in 
.UL do 's).
If 
.UL i
reaches zero,
the card is all blank.
.PP
This code is rather nasty to write with a regular Fortran
.UC DO ,
since the loop must go forward,
and we must explicitly set up proper conditions
when we fall out of the loop.
(Forgetting this is a common error.)
Thus:
.P1 1
.ta .3i .6i .9i 1.2i 1.5i 1.8i
	DO 10 J = 1, 80
		I = 81 - J
		IF (CARD(I) .NE. BLANK) GO TO 11
10	CONTINUE
	I = 0
11	...
.P2
The version that uses the
.UL for
handles the termination condition properly for free;
.UL i
.ul
is
zero when we fall out of the
.UL for
loop.
.PP
The increment
in a
.UL for
need not be an arithmetic progression;
the following program walks along a list
(stored in an integer array
.UL ptr )
until a zero pointer is found,
adding up elements from a parallel array of values:
.P1
sum = 0.0
for (i = first; i > 0; i = ptr(i))
	sum = sum + value(i)
.P2
Notice that the code works correctly if the list is empty.
Again, placing the test at the top of a loop
instead of the bottom eliminates a potential boundary error.
.SH
The ``repeat-until'' statement
.PP
In spite of the dire warnings,
there are times when one really needs a loop that tests at the bottom
after one pass through.
This service is provided by the
.UL repeat-until :
.P1
repeat
	\fIRatfor statement\fP
until (\fIlegal Fortran condition\fP)
.P2
The
.ul
Ratfor statement
part is done once,
then the condition is evaluated.
If it is true, the loop is exited;
if it is false, another pass is made.
.PP
The
.UL until
part is optional, so a bare
.UL repeat
is the cleanest way to specify an infinite loop.
Of course such a loop must ultimately be broken by some
transfer of control such as
.UL stop ,
.UL return ,
or
.UL break ,
or an implicit stop such as running out of input with
a
.UC READ
statement.
.PP
As a matter of observed fact[8], the
.UL repeat-until
statement is
.ul
much
less used than the other looping constructions;
in particular, it is typically outnumbered ten to one by
.UL for
and
.UL while .
Be cautious about using it, for loops that test only at the
bottom often don't handle null cases well.
.SH
More on break and next
.PP
.UL break
exits immediately from 
.UL do ,
.UL while ,
.UL for ,
and
.UL repeat-until .
.UL next
goes to the test part of
.UL do ,
.UL while
and
.UL repeat-until ,
and to the increment step of a
.UL for .
.SH
``return'' Statement
.PP
The standard Fortran mechanism for returning a value from a function uses the name of the function as a variable which can be assigned to;
the last value stored in it 
is the function value upon return.
For example, here is a routine
.UL equal
which returns 1 if two arrays are identical,
and zero if they differ.
The array ends are marked by the special value \-1.
.P1 1
.ta .3i .6i .9i 1.2i 1.5i 1.8i
# equal _ compare str1 to str2;
#	return 1 if equal, 0 if not
	integer function equal(str1, str2)
	integer str1(100), str2(100)
	integer i

	for (i = 1; str1(i) == str2(i); i = i + 1)
		if (str1(i) == -1) {
			equal = 1
			return
		}
	equal = 0
	return
	end
.P2
.PP
In many languages (e.g., PL/I)
one instead says
.P1
return (\fIexpression\fP)
.P2
to return a value from a function.
Since this is often clearer, Ratfor provides such a
.UL return
statement _
in a function
.UL F ,
.UL return (expression)
is equivalent to
.P1
{ F = expression; return }
.P2
For example, here is
.UL equal
again:
.P1 1
.ta .3i .6i .9i 1.2i 1.5i 1.8i
# equal _ compare str1 to str2;
#	return 1 if equal, 0 if not
	integer function equal(str1, str2)
	integer str1(100), str2(100)
	integer i

	for (i = 1; str1(i) == str2(i); i = i + 1)
		if (str1(i) == -1)
			return(1)
	return(0)
	end
.P2
If there is no parenthesized expression after
.UL return ,
a normal
.UC RETURN 
is made.
(Another version of
.UL equal
is presented shortly.)
.sp
.SH
Cosmetics
.PP
As we said above,
the visual appearance of a language
has a substantial effect
on how easy it is to read and understand
programs.
Accordingly, Ratfor provides a number of cosmetic facilities
which may be used to make programs more readable.
.SH
Free-form Input
.PP
Statements can be placed anywhere on a line;
long statements are continued automatically,
as are long conditions in
.UL if ,
.UL while ,
.UL for ,
and
.UL until .
Blank lines are ignored.
Multiple statements may appear on one line,
if they are separated by semicolons.
No semicolon is needed at the end of a line,
if
Ratfor
can make some reasonable guess about whether the statement
ends there.
Lines ending with any of the characters
.P1
=    +    -    *    ,    |    &    (    \(ru
.P2
are assumed to be continued on the next line.
Underscores are discarded wherever they occur;
all others remain as part of the statement.
.PP
Any statement that begins with an all-numeric field is
assumed to be a Fortran label,
and placed in columns 1-5 upon output.
Thus
.P1
write(6, 100); 100 format("hello")
.P2
is converted into
.P1
	write(6, 100)
100	format(5hhello)
.P2
.SH
Translation Services
.PP
Text enclosed in matching single or double quotes
is converted to
.UL nH...
but is otherwise unaltered
(except for formatting _ it may get split across card boundaries
during the reformatting process).
Within quoted strings, the backslash `\e' serves as an escape character:
the next character is taken literally.
This provides a way to get quotes (and of course the backslash itself) into
quoted strings:
.P1
"\e\e\e\(fm"
.P2
is a string containing a backslash and an apostrophe.
(This is
.ul
not
the standard convention of doubled quotes,
but it is easier to use and more general.)
.PP
Any line that begins with the character `%'
is left absolutely unaltered  
except for stripping off the `%'
and moving the line one position to the left.
This is useful for inserting control cards,
and other things that should not be transmogrified
(like an existing Fortran program).
Use `%' only for ordinary statements,
not for the condition parts of
.UL if ,
.UL while ,
etc., or the output may come out in an unexpected place.
.PP
The following character translations are made, 
except within single or double quotes
or on a line beginning with a `%'.
.P1
.ta .5i 1.5i 2i
==	.eq.	!=	.ne.
>	.gt.	>=	.ge.
<	.lt.	<=	.le.
&	.and.	|	.or.
!	.not.	^	.not.
.P2
In addition, the following translations are provided
for input devices with restricted character sets.
.P1
.ta .5i 1.5i 2i
[	{	]	}
$(	{	$)	}
.P2
.SH
``define'' Statement
.PP
Any string of alphanumeric characters can be defined as a name;
thereafter, whenever that name occurs in the input
(delimited by non-alphanumerics)
it is replaced by the rest of the definition line.
(Comments and trailing white spaces are stripped off).
A defined name can be arbitrarily long,
and must begin with a letter.
.PP
.UL define
is typically used to create symbolic parameters:
.P1
define	ROWS	100
define	COLS	50
.if t .sp 5p
dimension a(ROWS), b(ROWS, COLS)
.if t .sp 5p
	if (i > ROWS  \(or  j > COLS) ...
.P2
Alternately, definitions may be written as
.P1
define(ROWS, 100)
.P2
In this case, the defining text is everything after the comma up to the balancing
right parenthesis;
this allows multi-line definitions.
.PP
It is generally a wise practice to use symbolic parameters
for most constants, to help make clear the function of what
would otherwise be mysterious numbers.
As an example, here is the routine
.UL equal 
again, this time with symbolic constants.
.P1 3
.ta .3i .6i .9i 1.2i 1.5i 1.8i
define	YES		1
define	NO		0
define	EOS		-1
define	ARB		100

# equal _ compare str1 to str2;
#	return YES if equal, NO if not
	integer function equal(str1, str2)
	integer str1(ARB), str2(ARB)
	integer i

	for (i = 1; str1(i) == str2(i); i = i + 1)
		if (str1(i) == EOS)
			return(YES)
	return(NO)
	end
.P2
.SH
``include'' Statement
.PP
The statement
.P1
	include file
.P2
inserts the file
found on input stream
.ul
file
into the
Ratfor
input in place of the
.UL include
statement.
The standard usage is to place 
.UC COMMON
blocks on a file,
and
.UL include
that file whenever a copy is needed:
.P1
subroutine x
	include commonblocks
	...
	end

suroutine y
	include commonblocks
	...
	end
.P2
This ensures that all copies of the 
.UC COMMON
blocks are identical
.SH
Pitfalls, Botches, Blemishes and other Failings
.PP
Ratfor catches certain syntax errors, such as missing braces,
.UL else
clauses without an
.UL if ,
and most errors involving missing parentheses in statements.
Beyond that, since Ratfor knows no Fortran, 
any errors you make will be reported by the Fortran compiler,
so you will from time to time have to relate a Fortran diagnostic back
to the Ratfor source.
.PP
Keywords are reserved _
using
.UL if ,
.UL else ,
etc., as variable names will typically wreak havoc.
Don't leave spaces in keywords.
Don't use the Arithmetic
.UC IF .
.PP
The Fortran
.UL nH
convention is not recognized anywhere by Ratfor;
use quotes instead.