Emulating Goto in Scheme with Continuations
terezi.pyrope.net
Emulating Goto in Scheme with Continuations
1–10 of 26 posts
Re: Emulating Goto in Scheme with Continuations
#2I 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.
Re: Emulating Goto in Scheme with Continuations
#3I 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.
Constrained GOTO semantics sounds a lot like delimited continuations. Indeed I think Scheme continuations are a little too powerful for regular use by having the possibility of global effect (like longjmp). Delimited continuations make the effect more local.
Re: Emulating Goto in Scheme with Continuations
#4I 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.
Constrained GOTO semantics sounds a lot like delimited continuations. Indeed I think Scheme continuations are a little too powerful for regular use by having the possibility of global effect (like longjmp). Delimited continuations make the effect more local.
If you'll excuse the self-post, here's a blog post on goto with delimited continuations.
https://rd.nz/2009/03/goto-in-scala.html
It uses an experimental compiler plugin for the Scala compiler. It's typesafe at compile time. At runtime unfortunately it relies on exceptions for control flow.
Re: Emulating Goto in Scheme with Continuations
#5I 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.
Constrained GOTO semantics sounds a lot like delimited continuations. Indeed I think Scheme continuations are a little too powerful for regular use by having the possibility of global effect (like longjmp). Delimited continuations make the effect more local.
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 that.
Re: Emulating Goto in Scheme with Continuations
#6Earlier quoted context omitted.
Constrained GOTO semantics sounds a lot like delimited continuations. Indeed I think Scheme continuations are a little too powerful for regular use by having the possibility of global effect (like longjmp). Delimited continuations make the effect more local.
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.
Re: Emulating Goto in Scheme with Continuations
#7I 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.
Do you use it mostly as "labeled breaks" or to throw the values out of closures?
Re: Emulating Goto in Scheme with Continuations
#8I 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.
Do you use it mostly as "labeled breaks" or to throw the values out of closures?
I haven't used it much at all, to be clear. I just found it surprisingly fun the last few times I played with it.
The specific thing it made a lot easier was implementing algorithms the way that Knuth writes them down. Which is very much a set of steps with specific calls on what step to go to next.
I think the reason I found it fun to play with was that I found that style of laying out what needed to be done was easier to work with than the standard breakdown that making everything a function or an object seems to require. For me, it was a lot easier.
Edit: I have one of the times I used this here: https://taeric.github.io/many_sums.html I did not put any effort into cleaning up that code, though. So it can probably work as an argument in either direction. :D
Re: Emulating Goto in Scheme with Continuations
#9Note that the example program:
(define (displayln obj)
(display obj)
(newline))
(define cont #f)
(displayln
(call/cc
(lambda (k)
(set! cont k)
"cont set")))
(begin
(displayln "procedure called")
(displayln "after procedure call")
(cont "continuation called")
(displayln "after continuation call"))
This is because every top-level form in the REPL has an implicit continuation "return to the REPL and read more input".
So after "continuation called" is printed, we go back to the prompt and await more input.
However, if this code is saved in a file and you run it (e.g. "guile my-script.scm") then the continuation of the top-level `displayln` call is the top-level `begin` form, and we enter an infinite loop.
Re: Emulating Goto in Scheme with Continuations
#10I 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.
From John Cowan:
TAGBODY doesn't actually require continuations, delimited or undelimited, just proper tail calling. A macro can rewrite each section of the TAGBODY into a procedure nested within a `let` that tail-calls its successor, and the body of the `let` tail-calls the first procedure. (GO tag) is then equivalent to just (tag). This is a great way of doing state machines. Chicken has a tagbody egg, I think.