statement level flow of control gotos and other weirdness copyright © 2003-2014 by curt hill

Statement Level Flow of Control

GOTOs and Other Weirdness

Copyright © 2003-2014 by Curt Hill

Unconditional Branching• This is an inheritance from machine

language through FORTRAN and other 1960s imperative languages

• The controversy has already been discussed

• The problem is: How did I get here?• We always have this problem with

flow of control:– Through the then or the else?– Did the leading decision loop execute

zero times or was the last statement in the loop


How did I get here?

• In the case of decisions and loops you can form a predicate that describes how you got there– With a loop you also know that

you could not arrive unless the loop exit condition was true

• In the case of goto this predicate is substantially more complicated


Issues

• Form of the label?– Does it need declaration?

• Location of the target?– Usually in this unit or elsewhere?


Form of labels• FORTRAN, Pascal use unsigned

integers– Pascal declares them in advance

to discourage their use

• ALGOL 60, C, C++ use identifier forms

• Ada brackets labels<<LABEL>>– Makes the label easy to see


Two Examples


Ada goto target; …<<target>> x:=x+1; Pascal Label 4; { In declarations } …goto 4; …4: x:=x+1;

Others

• COBOL can change the destination with an Alter statement• GOTO can be nullified or change

destination• How does this affect readability?

• PL/I allows them to be variables so that the value can be assigned– The label to be branched to may

change during the course of execution


PL/I Example 1


PL/I simple goto and label goto L1; L1: x = x+1;. . .L2: z = z*2;. . .

PL/I Example 2


The not so simple:DECLARE LX LABEL;DECLARE L_AR(5) LABEL;… LX = L2;… GOTO LX;… GOTO L_AR(K);…L2: z = z*2;

Restrictions on gotos

• Can you branch into an subroutine or only out of it?

• Pascal allows you to branch out of a subroutine into its calling ancestor

• FORTRAN did allow a branch out of routine and into another one


Typical Use• In the modern times the GOTO is

mainly an error exit• Pascal is typical

– We use it to bail from deeply nested constructs, including subroutines

– Many implementations of Pascal and other languages force the GOTO to stay local

• Error handling has largely supplanted the need for the GOTO


Guarded commands• Developed in the context of

proofs of correctness– Started by Dijkstra– Most of the work has been done

in the Artificial Intelligence area

• Motivation: If the order of evaluation is not important the program should not force one


Guarded IF

• The if has several arms– Boolean followed statement– Of the true booleans any or all

could be picked– Non-deterministic

• Similar to the LISP COND


Guarded if• Form:

if[ ] a>b -> c = a[ ] a=b -> c = a[ ] a<b -> c = bfi

• There could be as many booleans and statements as you would like

• One that was true would be non-deterministically chosen executed


Guarded Loop

• There was also a loop construct

• The loop could not exit as long as one Boolean was true:do[ ] q1 > q2 swap(q1,q2);[ ] q2 > q3 swap(q2,q3);[ ] q3 > q4 swap(q3,q4);od


Implementations

• Scarce• Computers are inherently

deterministic machines– Extra work to make sequential

constructs non-deterministic

• Gained little popularity in sequential languages– More in concurrent languages


Guarded Again

• There have been numerous proposals – None have caught on

• The idea is that we can mathematically develop programs that are provably correct– The proof is generated as a side

effect of the writing the program


Finally

• The structured programming school has dominated thinking in imperative languages concerning flow of control

• The GOTO has all but disappeared– This is why SNOBOL is so difficult

• The proof of correctness factions have made little impact


statement level flow of control gotos and other weirdness copyright © 2003-2014 by curt hill

Documents