I confess I like Common Lisp's TAGBODY far more than I feel like I should. Having constrained GOTO semantics to a short section of the codebase is surprisingly useful.
[deleted]
Emulating Goto in Scheme with Continuations
11–20 of 26 posts
Re: Emulating Goto in Scheme with Continuations
#12I confess I like Common Lisp's TAGBODY far more than I feel like I should. Having constrained GOTO semantics to a short section of the codebase is surprisingly useful.
Following the recommendations of Knuth, the language Mesa, which was implemented at Xerox during the seventies, and which was a source of inspiration for various later languages, including Modula, Ada and Python, included a form of "restricted GOTO" which is the most useful kind of GOTO in my opinion.
The Mesa restricted GOTO allowed jumping forwards, but not backwards, and it allowed jumping towards an outer block, but not towards an inner block.
These 2 restrictions eliminate all the "harmful" features of the traditional GOTO, while retaining its advantages for handling exceptional conditions or for terminating multiple levels of nested program structures.
The Common Lisp TAGBODY appears to be only partially restricted, by allowing backward jumps, so it does not prevent the kind of hard-to-understand program structures for which GOTO was criticized.
GOTOs in random directions may be used to implement state machines, but such state machines can still be implemented in a language with restricted GOTO by not using GOTO, but by using mutually recursive procedures, if tail-call optimization is guaranteed.
Re: Emulating Goto in Scheme with Continuations
#13If you are into continuations, check Friedman's papers on ReadScheme.
https://github.com/schemedoc/bibliography/blob/master/page6....
In particular look at "Programming with Continuations", "Engines Build Process Abstractions" and "Continuations and Coroutines".
Re: Emulating Goto in Scheme with Continuations
#14Here's my very funny implementation of delimited continuation in plain C with zero ASM usage (with help from a specific compiler built-in)
https://gist.github.com/Trung0246/8f801058212d3bbbef82690a31...
Demo (old version with outdated compile flag but still works): https://godbolt.org/z/n9ch4TM3s
It works for gcc/clang/msvc with -O0, -O1, -O2, and even -O3
Re: Emulating Goto in Scheme with Continuations
#15I confess I like Common Lisp's TAGBODY far more than I feel like I should. Having constrained GOTO semantics to a short section of the codebase is surprisingly useful.
Following the recommendations of Knuth, the language Mesa, which was implemented at Xerox during the seventies, and which was a source of inspiration for various later languages, including Modula, Ada and Python, included a form of "restricted GOTO" which is the most useful kind of GOTO in my opinion. The Mesa restricted GOTO allowed jumping forwards, but not backwards, and it allowed jumping towards an outer block,…
I'm not clear that jumping backwards is that tough to reason with. Notably, Knuth's algorithms do that quite commonly, right?
I do think they need to be somewhat constrained to not jump to places that need new things initialized. Which, it is truly mind blowing to know folks used to just jump straight into other functions. Mid function. Because why not.
Re: Emulating Goto in Scheme with Continuations
#16[deleted]
Re: Emulating Goto in Scheme with Continuations
#17Earlier quoted context omitted.
Delimited continuations always bounced off of me. In theory, they should be a lot like coroutines? I think, in practice, I just never really internalized all that goes into managing the current "environment" for a piece of code that is managed by the call state. Like, I have a few partial mental models for everything that they pull together. I haven't really tried to build on that, though. Should put some time to tha…
You could implement coroutines with deliminated continuations, which is probably the best way to use deliminated continuations.
Effect handlers would like to have a word.
Re: Emulating Goto in Scheme with Continuations
#18Earlier quoted context omitted.
Following the recommendations of Knuth, the language Mesa, which was implemented at Xerox during the seventies, and which was a source of inspiration for various later languages, including Modula, Ada and Python, included a form of "restricted GOTO" which is the most useful kind of GOTO in my opinion. The Mesa restricted GOTO allowed jumping forwards, but not backwards, and it allowed jumping towards an outer block,…
I'm not clear that jumping backwards is that tough to reason with. Notably, Knuth's algorithms do that quite commonly, right? I do think they need to be somewhat constrained to not jump to places that need new things initialized. Which, it is truly mind blowing to know folks used to just jump straight into other functions. Mid function. Because why not.
jumping backward creates all the non-linear issues I assume
Re: Emulating Goto in Scheme with Continuations
#19Earlier quoted context omitted.
I'm not clear that jumping backwards is that tough to reason with. Notably, Knuth's algorithms do that quite commonly, right? I do think they need to be somewhat constrained to not jump to places that need new things initialized. Which, it is truly mind blowing to know folks used to just jump straight into other functions. Mid function. Because why not.
jumping backward creates all the non-linear issues I assume
Fair that it can create some. But just allowing of nested loops already creates some of these. And, I know folks have tried to disallow loops, but that feels extreme.
Again, I would point to many of Knuth's descriptions as already allowing jumps forward and backward in steps as evidence that they can be useful.
Re: Emulating Goto in Scheme with Continuations
#20Earlier quoted context omitted.
jumping backward creates all the non-linear issues I assume
Fair that it can create some. But just allowing of nested loops already creates some of these. And, I know folks have tried to disallow loops, but that feels extreme. Again, I would point to many of Knuth's descriptions as already allowing jumps forward and backward in steps as evidence that they can be useful.
When backward jumps are allowed you can create loops that are much more tangled and incomprehensible than when you are nesting the loop structures of modern languages.
With backward jumps, you can make multiple loops that are not nested, but you could visualize them as a complex graph that has sequences of instructions in the nodes and which has multiple cycles through which the execution may or may not pass and which intersect each other. Good luck to understand how the code works, because you cannot separate parts of it that can be understood independently, like when using the "structured programming" that is ubiquitous in modern programming languages.
Such indecomposable complex multiple loops were not uncommon before 1970 in languages like FORTRAN or COBOL, and precisely this kind of control structures were the reason why the use of GOTO was criticized and considered harmful.