Indeed, GO TO is not that unstructured; it can be said to have a fairly precise semantics of "sets the continuation of the program to <label>; does not proceed to the next statement.". Though if you want to analyze the semantics of a GO TO-using program, it's practically a required step to endow all of your labels with appropriate COME FROM annotations, marking the branches it could be reached from - and that's a whole-program analysis, at least in principle. That's the point where you're giving up modularity!

Why? You can easily emulate a state machine with a while loop, a switch case and one more level of if-branches. Abstracting those in a framework doesn't make it unstructured IMO.

> You can easily emulate a state machine with a while loop, a switch case and one more level of if-branches.

You can easily emulate GOTO much the same way.

obviously, as long as the language is turing complete, but you just converted an unstructured program to a structured one.

To the same extent, and in the same way, as you did when you converted a state machine the same way? I still don't get what distinction you're drawing between state machine style and GOTO style.

And gained nothing except more verbose syntax. The goto spaghetti is still spaghetti whether you use "goto" or "switch".

Disagree. You eliminate backward gotos except for the while loop, which is much more clearly communicating the way to extend the code (by adding more states or state transitions) to the next person taking over. I‘m not categorically against goto in certain contexts (like C based systems programming), but IMO backwards jumps with goto need to be eliminated.