[neilv]

I don't know whether it helps, but here's another explanation that doesn't involve a visual programming language:

First, imagine that procedures (or functions) are first-class values, like in some languages are called "anonymous functions", "closures", "lambdas", etc.

Now imagine that every procedure call is effectively a goto with arguments... and the familiar part about being able to return from that procedure, to its calling point, is implemented by an implicit additional value created at calling time... which is a "continuation" procedure with argument(s) that you call to return the value(s) from the other procedure.

To make it first-class continuations, imagine that "continuation" procedure value you call to return the value(s) from another procedure... can be made accessible to the program as a first-class value. Which means you can store it in a variable or data structure like any other value. And you can call that "continuation" procedure value multiple times -- returning to that dynamic state of the calling context in the program many times.

It's one of those things that application code almost never uses directly, but that could be super useful and simplifying in the implementation of another programming language, or carefully controlled in particular libraries (e.g., you wanted to make a stateful Web backend library or DSL that made it really easy to express the logic for some kind of interaction tree responding to multiple steps of form input).

[Someone]

An alternative way to look at for C/C++/pascal/… programmers it is by looking at the return keyword not as a keyword, but as an implicit argument that’s a pointer to a function. Imagine this would work:

   global fooBack
   global barBack
   main() {
     print foo()
   }
   foo() {
     fooback = return
     bar()
     return “foo”
   }
   bar() {
     barBack = return
     if randomBool
       fooBack(“bar”)
     else
       return “bar”
   }

and that, 50% of the time, woud print “bar”.

In a C-like system with a call stack, that would give you a nicer setjmp (still with quite a few limitations). Systems with true continuations would allow code to call ‘up the stack’ for example if main were to call barBack in the scenario above. That wouldn’t work in C as bar’s stack frame wouldn’t exist anymore.

[plagiarist]

I think `bar` being able to return from `foo` has little difference to throwing exceptions in various OOP languages. But the C-style paradigm makes it more confusing for different scenarios, like as you describe with calling the deeper "return" from main.

[harryposner]

So the particular example here isn’t too different from exceptions. You’re unwinding the stack up to a predefined point— here, the callsite of foo, where with exceptions it would be up to the surrounding try/catch. Scala actually implements non-local returns (the only practical use I’ve had for call/cc) using exceptions: https://tpolecat.github.io/2014/05/09/return.html

[HexDecOctBin]

I'm not an expert, but I think the difference is that in exceptions, stack in unwound; while in continuations, all stack frame hang around in a sea of stack frames waiting to be garbage collected when no one holds a reference to them anymore. This would imply that you can jump into the same stack frame multiple times, or do other weird things.

[harryposner]

> This would imply that you can jump into the same stack frame multiple times, or do other weird things.

Yep— this is how you can implement the `amb` operator with call/cc: https://ds26gte.github.io/tyscheme/index-Z-H-16.html

[plagiarist]

Sure, but then the context of the C family of languages hinders any comprehension of these different styles of use.

[HexDecOctBin]

This is great, I finally understand how continuations work (since I now see how they might be implemented in the runtime). Thanks!

Could you provide a similar example of what delimited continuations are?