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) [...] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%