The "catch-22" is that "improved readability" is in the eye of the beholder.

My Fortran 90 textbook has an example on page 222-223 that is as close as
any I have found to justifying GO TO in comparison with other constructs
currently in Fortran. The text notes that Charles Zahn's 1974 proposal would
be an elegant solution - I seem to recall that Jeanne Martin, Walt Brainerd
proposed a "Zahn construct" for F90.

= = QUOTE FROM "FORTRAN 90" BY LOREN P MEISSNER = =

Consider the following fragment from a program to search for a key in an
ordered list stored as an array. If there is an item in the list that
matches the key, we wish to update the existing item; if there is no
matching item, we wish to insert it as a new item in the list (presumably
both updating and insertion are nontrivial operations requiring extensive
blocks of statements).

do I = 1, List_Length
	if (List(I) == Search_Key) then
			! Update
		else if (List(I) > Search_Key) then
			! Insert
	else
			! Continue searching
	end if
end do
	! Insert (List is exhausted; Search_Key not found)

There are two ways of detecting an unsuccessful search in an ordered array.
If we encounter a list item larger than the search key, we know that we have
gone beyond the point where a matching item would be if it were in the list.
Or, if we reach the end of the list without matching the search key, we know
that the search has failed. We could position the Insert statements after
the loop and put an exit statement in the else if block. But then where do
we put the Update operation? Or, if we position the Update statements in the
then block, what do we do at the end of the Update operation? An exit from
that point will still jump to the Insert statements.

There are several suboptimal alternatives, some of which are data-oriented.
Probably the preferred modern method is to set a Flag variable to indicate
whether to insert or update; an if or a case construct following the loop
can branch according to the Flag value. Ahead of the loop, we initialize the
Flag to indicate the insert option.

Other solutions are control-oriented. If the search is implemented as a
procedure, we can put the Update statements in the then block and follow
them with a return from the procedure (see Section 7.3) to avoid jumping to
the Insert statements at the end of the loop. Instead of obscuring the loop
structure, it may be preferable to write the Update operation as a separate
procedure and call it from the then block.

Another control-oriented solution, in good traditional Fortran style, is a
go to statement (see Appendix D.4) in the then block, which jumps to the
Update statements that we move to some other place in the program.
Conscientious objectors to go to can achieve the same effect (in a decidedly
inferior way) by creating a "dummy loop" and jumping to the end of the loop
with an exit statement. The dummy loop should be an indexed do that will be
executed exactly once.

= = END OF QUOTE = =

= Loren P Meissner
Genealogist Barbara Yancey Dore asks:
Can a first cousin, once removed, ever return?


-----Original Message-----
From:	[log in to unmask]
[mailto:[log in to unmask]] On Behalf Of
[log in to unmask]
Sent:	Wednesday, August 30, 2000 5:00 PM
To:	[log in to unmask]
Subject:	Re: GO TO


[...]

I can think of NO example of prospective code design where GO TO could not
be replaced in modern FORTRAN (with improved readability) [...]



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%