Are there any continuation implementations in Common Lisp?
Writing a Lisp: Continuations
21–30 of 51 posts
Re: Writing a Lisp: Continuations
#22Are there any continuation implementations in Common Lisp?
Re: Writing a Lisp: Continuations
#23I remember trying to learn continuations during my CS degree, and evidently even today I still don't understand them. The examples don't seem to help either – how exactly does the control flow function?
This page helped me quite a bit a few years ago http://blog.theincredibleholk.org/blog/2013/11/27/continuati...
Re: Writing a Lisp: Continuations
#24Do any non-Lisp/Scheme languages have continuations?
There's lots of continuation styles & libraries, but most are delimited continuations. In my opinion, delimited ones are far cleaner to implement and to work with than the more universal continuations of Scheme. call/cc, as a product of Scheme's efforts on simplicity[1], has to encompass a larger amount of low-level state than most real-world uses of it use (and it's used far less frequently in "real applications" th…
Re: Writing a Lisp: Continuations
#25Earlier quoted context omitted.
There's lots of continuation styles & libraries, but most are delimited continuations. In my opinion, delimited ones are far cleaner to implement and to work with than the more universal continuations of Scheme. call/cc, as a product of Scheme's efforts on simplicity[1], has to encompass a larger amount of low-level state than most real-world uses of it use (and it's used far less frequently in "real applications" th…
Any recommendations for write-ups on how delimited continuations are implemented?
the distinction is that in scheme, where (at least in the standard implementation) each function call takes an implicit continuation and the code is everted using a bulk cps-transform before being interpreted or further compiled.
in this later case, its possible to use call/cc to create a continuation at any point in a 'normal' program, without having to construct the control flow explicitly. its this 'continuations everywhere' approach that can burden the runtime with a lot of consequences, possibly even precluding the use of a stack at all depending on the implementation.
in the former case you can basically do by-hand cps or event-handling in anything. asm, C, c++, python (3), go, js..
Re: Writing a Lisp: Continuations
#26Continuations are strangely underused, as they enables writing long-living processes in a simple way, without having to keep them in running in a thread, or even in memory. Then a real programming language can replace all "business processing" crap languages. Let's say you write a framework that escapes to a continuation whenever the "process" is waiting for Futures or Promises to complete, and returns the thread to…
Re: Writing a Lisp: Continuations
#27Do any non-Lisp/Scheme languages have continuations?
C# has async/await and TPL, e.g. .ContinueWith(...) Javscript has promises and async/await
I know we're not meant to comment on downvoting but I want to uncover the error in my understanding of this subject because at least 3 people downvoted but there is no reply yet??
Re: Writing a Lisp: Continuations
#28Do any non-Lisp/Scheme languages have continuations?
Here's the obligatory "Haskell has a monad for that" comment http://hackage.haskell.org/package/mtl-2.2.1/docs/Control-Mo...
Re: Writing a Lisp: Continuations
#29Do any non-Lisp/Scheme languages have continuations?
There's lots of continuation styles & libraries, but most are delimited continuations. In my opinion, delimited ones are far cleaner to implement and to work with than the more universal continuations of Scheme. call/cc, as a product of Scheme's efforts on simplicity[1], has to encompass a larger amount of low-level state than most real-world uses of it use (and it's used far less frequently in "real applications" th…
If we place a prompt at the top of the main function of the program and use that for making delimited continuations, we basically get regular continuations: continuations that can potentially return all the way to the top, just as far as regular continuations.
(We can even set it up so that if any such a delimited continuation does actually get that far, the process will exit.)
Delimiting is actually an extra bit of expressive power, not a constraint.
We can compare the delimited continuation to a boomerang or yo-yo: we know that it will only go so far, and then return. That's why it can be used as a function. When resumed, it will get no farther than the delimiting prompt, and then whatever value pops out of that contour bounces back to us, who resumed the continuation.
The continuation won't keep going and then bail the program.
Regular continuations can simulate delimited ones: there is some jig put in place (with macros or whatever) which catches when the continuation has bubbled up to the faked-out prompt, and redirects the control---by invoking some other continuation that represents the boomerang return. Or something like that.
There are tricks for implementing the delimited ones, though, that don't involve such a thing. Like pushing the delimited continuation onto the stack, so that the return out of the prompt is just an actual return. I.e. entire "future computation" of the delimited continuation is just "installed" into the stack at the current top. The activation frames are hooked up, and then there is a new topmost frame: that of the restarted continuation, to which the procedure context is restored.
Re: Writing a Lisp: Continuations
#30Are there any continuation implementations in Common Lisp?