Jumps to arbitrary instruction addresses (goto) are unavoidable and the dispute is about how to structure such jumps by effectively replacing goto by some other mechanism:
- Introduce scopes and program structure instead of explicit labels (instruction addresses) and using control flow operators which rely on this structure
- Procedures and procedure calls
- Overriding and virtual functions where the system knows how to find the next instruction to jump to
- Concurrency and multi-threading where resume operation means essentially jumping to some (dynamic, not static) instruction address.
I think we should distinguish between gotos at language level and jumps in the underlying machine code. Djikstra was concerned about correctness at the language level. The whole point is that a structured high level language can provide correctness guarantees which is not present in the underlying machine code, even though all control structures compiles down to jumps.
Gotos are not unavoidable in high level languages.
> I think we should distinguish between gotos at language level and jumps in the underlying machine code.
Is there any non-syntactic difference between these two lines?
JMP Ox1234
GOTO label_1234
I think they are identical and the question is only where target labels can reside, how they are represented, and when the jumps are triggered (operation).
You lost me here. Is this assembler? The question is if and when to use goto in higer-level code, not how to use jumps in machine code, which is a completely different question. What keyword you use for the instruction does not matter.
- Introduce scopes and program structure instead of explicit labels (instruction addresses) and using control flow operators which rely on this structure
- Procedures and procedure calls
- Overriding and virtual functions where the system knows how to find the next instruction to jump to
- Concurrency and multi-threading where resume operation means essentially jumping to some (dynamic, not static) instruction address.
- Asynchronous and even-driven programming