Flow-control structures: Difference between revisions

Fortran offers <code>GO TO ''label''</code> where ''label'' is a number, an integer, which is prefixed to some executable statement according to the rules of Fortran source layout. Fortran has no reserved words and gives no significance to spaces, so that <code>G O TO 12 3 4</code> is just as valid as <code>GO TO 1234</code> and other usages. As a result of this, text labels are difficult to fit into the syntax so that the likes of <code>GO TO START</code> are unavailable. However, a compiler may offer the "assigned GO TO" facility, with statements such as <code>ASSIGN 120 TO THENCE</code> scattered about: 120 is a statement label, not an integer, and any statement label may be assigned to variable THENCE (which is an integer variable) as execution proceeds. Then <code>GO TO THENCE</code> will cause a GO TO for the current address held in THENCE... Should you yield to temptations such as <code>THENCE = THENCE - 6</code> (treating it as an ordinary integer), a subsequent <code>GO TO THENCE</code> may end execution with an error message, or something else...

There is also a "computed GO TO" with syntax like <code>GO TO (101,50,75,50), ''n''</code> where ''n'' is an integer variable (or expression) that selects from the list of statement labels: in this example if its value is three, then the third label, 75, will be selected. If the value is less than one or greater than threethe number of labels in the list, odd behaviour is likely, differing by compiler. Possibly by continuing with the next statement, or ending execution with an error message, or making a leap into the void.

An implicit GO TO can appear in READ and WRITE statements (and a few others), that will be taken should there be certain difficulties. InThus <code>READ (IN,6,END = 200, ERR = 300) STUFF</code> that reads input from I/O unit IN (an integer value) into variable STUFF according to the FORMAT statement labelled 6,. But should there be instead an end-of-file, rather than ending execution with an error code, execution will GO TO label 200, while if there should arise some difficulty with the data format of the incoming data (two decimal points in one data field, ''etc.'') then execution will goGO toTO label 300. FORMAT statements, though labelled, are not considered suitable destinations for GO TO jumps.

Similar possibilities arise with alternate returns from subroutines and functions, for instance to handle error conditions it might wish to report as with the READ statement. For exampleThus, <code>CALL FRED(THIS,*123,*444THENCE)</code> invokes a subroutine FRED with three parameters: THIS, then two oddities. The leading * (or &) signifies that these are no ordinary integers (or expressions) but instead are the labels of two statements somewhere within the calling routine. Subroutine FRED might return in the normal way so that execution continues with the following statement, or, it may instead return with a GO TO for one of the labels...<lang Fortran> SUBROUTINE FRED(X,*,*) !With placeholders for unusual parameters.

More delicate souls prefer to see an integer parameter whose value will be set by FRED according to the desired condition, and every call to FRED would be followed by a computed GO TO on that value. Except that this statement is also disapproved of, so one is encouraged to code IF, or CASE, ''etc.'' and enjoy the repetition.