3 ms·

The explanation for call/cc has always been extremely roundabout and confusing to me, especially since setjmp/longjmp aren't themselves typically used in C code

The explanation for call/cc has always been extremely roundabout and confusing to me, especially since setjmp/longjmp aren't themselves typically used in C code. Here's a hopefully simple explanation: (call/cc f) means "call f and pass it a customized 'return' procedure, which, when invoked with your desired return value, would make this call/cc invocation return that value right here and continue executing the program".

sillysaurus3 8y ago
Simple, but missing many parts. For example, what happens to variables on the stack? The heap? What does it mean to continue execution from “here” — from this point in time? Does that mean file handles will be closed or re-opened to match the current state of the program? These questions usually have straightforward answers, but some are counterintuitive.
- mehrdadn 8y ago
  What do you mean what happens to them? Wouldn't they just be kept alive with the same semantics as how a variable used in a nested function is kept alive? Or is there more that I'm not aware of? If that's all there is to it, the semantics should be second nature if you've done Java, Python, or any other GC'd language, right?
  - sillysaurus3 8y ago
    That’s one option. But the unfortunate conclusion of that choice is that continuations leak a lot of memory. One shot continuations are better, since it frees up the variable references.
    - mehrdadn 8y ago
      I don't see how this is different from lambdas in general, in JS/Python/etc... wouldn't it only be held as long as the variables are alive? If you use the callback only once then they should be eligible to be freed after being used once.
      - sillysaurus3 8y ago
        http://okmij.org/ftp/continuations/against-callcc.html http://okmij.org/ftp/continuations/against-callcc.html is pretty informative. It was kind of eye opening to see just how many corner cases there are when dealing with continuations. (See the section “memory leaks”.)
        mehrdadn 8y ago
        Thanks for the link! Unfortunately I don't understand what it's saying the issue is... would you have a simple example to illustrate? It's been years since I did Scheme, I've never actually needed to use call/cc in a program, and I'm not advanced enough in Scheme to have seen shift/reset (as with call/c, their documentation is not quite clear). :\
        sillysaurus3 8y ago
        I could, but not at 3 AM. :) I'll try to remember tomorrow.
cryptonector 8y ago
Steps to understanding call/cc (for C programmers): 0. recognize that function return in C (and many langs) is just like implicitly calling a function of one argument (the return value) 1. further recognize that these "return functions" are *closures*! on the stack they are passed as both, an instruction pointer *and* the frame pointer of the frame into which to return! 2. add closures (somewhat like GCC local functions) 3. make a builtin macro-like thing that lets you call a C function with an alternative "return-function" argument that is like any other function (of one argument), and particularly allows local function references to be given as a return-function 4. make a builtin macro-like thing to get at the current frame's return-function "argument" -- i.e., reify the previously implicit current continuation 5. screw the function call stack, change the code generator and run-time to allocate function frames on a heap (and add garbage collection) Presto, you have call/cc. Shorter: allocate function frames on the stack, reify the return function argument closure and call it the continuation. To "reify" means to give reality to something that was previously hidden / implied. call/cc looks really awesome until you realize that it has / causes problems. One problem is that if you hold on to a reference to a continuation then you're actually preventing GC of all the stack frames captured by that continuation. Then there are thread safety issues... Any language that has variables (as opposed to lexical, immutable bindings) will have thread safety problems. Imagine using closures as callbacks, and having said closures change variables they close over, and now imagine them racing against each other to modify the same variables. Well, in a Scheme continuations are strung-up closures, so now imagine multiple threads trying to call the same continuation. These thread-safety problems run deep, and will tend to push one towards Haskell or Rust. Really, call/cc is a bit of a parlor trick :) -- a fascinating parlor trick, but still a parlor trick. If you want much much more detail, I recommend two great books that deal with this subject: - On Lisp (by Paul Graham) - Lisp In Small Pieces In On Lisp, Paul Graham has a chapter where he builds a set of macros that give you Scheme-style continuations with minimal compromises in how you write Lisp code. Lisp In Small Pieces is all about writing Lisp/Scheme interpreters and compilers, so it touches on all of this depth and great detail.
- cryptonector 8y ago
  > Shorter: allocate function frames on the stack, reify the return function argument closure and call it the continuation. To "reify" means to give reality to something that was previously hidden / implied. Oops, s/stack/heap/.

sillysaurus3 8y ago

Simple, but missing many parts. For example, what happens to variables on the stack? The heap? What does it mean to continue execution from “here” — from this point in time? Does that mean file handles will be closed or re-opened to match the current state of the program? These questions usually have straightforward answers, but some are counterintuitive.

mehrdadn 8y ago
What do you mean what happens to them? Wouldn't they just be kept alive with the same semantics as how a variable used in a nested function is kept alive? Or is there more that I'm not aware of? If that's all there is to it, the semantics should be second nature if you've done Java, Python, or any other GC'd language, right?
- sillysaurus3 8y ago
  That’s one option. But the unfortunate conclusion of that choice is that continuations leak a lot of memory. One shot continuations are better, since it frees up the variable references.
  - mehrdadn 8y ago
    I don't see how this is different from lambdas in general, in JS/Python/etc... wouldn't it only be held as long as the variables are alive? If you use the callback only once then they should be eligible to be freed after being used once.
    - sillysaurus3 8y ago
      http://okmij.org/ftp/continuations/against-callcc.html http://okmij.org/ftp/continuations/against-callcc.html is pretty informative. It was kind of eye opening to see just how many corner cases there are when dealing with continuations. (See the section “memory leaks”.)
      - mehrdadn 8y ago
        Thanks for the link! Unfortunately I don't understand what it's saying the issue is... would you have a simple example to illustrate? It's been years since I did Scheme, I've never actually needed to use call/cc in a program, and I'm not advanced enough in Scheme to have seen shift/reset (as with call/c, their documentation is not quite clear). :\
        sillysaurus3 8y ago
        I could, but not at 3 AM. :) I'll try to remember tomorrow.

cryptonector 8y ago

Steps to understanding call/cc (for C programmers): 0. recognize that function return in C (and many langs) is just like implicitly calling a function of one argument (the return value) 1. further recognize that these "return functions" are *closures*! on the stack they are passed as both, an instruction pointer *and* the frame pointer of the frame into which to return! 2. add closures (somewhat like GCC local functions) 3. make a builtin macro-like thing that lets you call a C function with an alternative "return-function" argument that is like any other function (of one argument), and particularly allows local function references to be given as a return-function 4. make a builtin macro-like thing to get at the current frame's return-function "argument" -- i.e., reify the previously implicit current continuation 5. screw the function call stack, change the code generator and run-time to allocate function frames on a heap (and add garbage collection) Presto, you have call/cc. Shorter: allocate function frames on the stack, reify the return function argument closure and call it the continuation. To "reify" means to give reality to something that was previously hidden / implied. call/cc looks really awesome until you realize that it has / causes problems. One problem is that if you hold on to a reference to a continuation then you're actually preventing GC of all the stack frames captured by that continuation. Then there are thread safety issues... Any language that has variables (as opposed to lexical, immutable bindings) will have thread safety problems. Imagine using closures as callbacks, and having said closures change variables they close over, and now imagine them racing against each other to modify the same variables. Well, in a Scheme continuations are strung-up closures, so now imagine multiple threads trying to call the same continuation. These thread-safety problems run deep, and will tend to push one towards Haskell or Rust. Really, call/cc is a bit of a parlor trick :) -- a fascinating parlor trick, but still a parlor trick. If you want much much more detail, I recommend two great books that deal with this subject: - On Lisp (by Paul Graham) - Lisp In Small Pieces In On Lisp, Paul Graham has a chapter where he builds a set of macros that give you Scheme-style continuations with minimal compromises in how you write Lisp code. Lisp In Small Pieces is all about writing Lisp/Scheme interpreters and compilers, so it touches on all of this depth and great detail.

cryptonector 8y ago
> Shorter: allocate function frames on the stack, reify the return function argument closure and call it the continuation. To "reify" means to give reality to something that was previously hidden / implied. Oops, s/stack/heap/.