Terrific! You named it -- Realistic Programming! Now you will be as famous as Dijkstra, Wirth, Knuth, Stroustrup, etc.! Yes, I saw some sense in some of the

Terrific! You named it -- Realistic Programming! Now you will be as famous as Dijkstra, Wirth, Knuth, Stroustrup, etc.! Yes, I saw some sense in some of the criticism of the GOTO statement, but, yes, I still use the GOTO statement. Main usage: In a function, some bad situation is detected. Okay, that code might write to a log file and should set a return code value. Then that code just does GOTO OUT which means, time to give and just get out'a here, ASAP, where OUT is a statement label of some code that does whatever general clean up is needed and just returns. There's another cute use of nearly a GOTO: For a loop, have something like DO FOREVER and in the code of the loop, maybe several places, decide when to get out'a the loop and then, do so with a statement LEAVE or some such which is really a GOTO the next statement after the end of the loop. It's essentially a GOTO and in some languages is implemented with an actual GOTO. But there was a totally sweetheart use of a GOTO in PL/I: In some code could have a statement ON FUBAR where FUBAR was a condition that could be raised, and this statement ON was followed by some code to be executed if condition FUBAR was raised. The ON statement made the condition FUBAR enabled and established what to do if the condition was raised. The code of the ON statement could have a GOTO. So, the code of function A has such an ON statement. Function A is called and the execution comes to the ON statement. Now the condition FUBAR is enabled and that ON unit is established for condition FUBAR should it be raised. If the code of function A returns, then that ON condition is no longer established. Function A calls function B which raises condition FUBAR. Then the code immediately jumps to the code of ON FUBAR. If that code executes a GOTO to a label in the code of function A, then all the code in the stack of active code from function A and lower is ended (e.g., storage automatically allocated is freed), and execution continues. So, look, Ma, a way to handle exceptional conditions that is easy to code and understand and does the usual, obvious stuff to clean up the mess for, e.g., no memory leaks. And could do GOTO X, and the X could be a statement label in any code so far called but not yet returned, and the label in the code most recently called but not yet returned would be the target of the GOTO. Again would get stack cleanup. Nice. Ah, Dijkstra would roll over, screaming. GOTOs are a common part of life: If get a flat tire, then raise an exceptional condition, cancel a lot of plans and work in progress, and go to the shop of the towing service and call a cab. If the computer processor fan stops and the processor overheats, then something similar. Lots of common situations in life.