Ian Bicking has an operational, concrete description of how continuations work.
Here's another way of explaining that sometimes works...
- Imagine running some code in a (good, hypothetical) debugger.
- Step through the code at the finest level of detail.
- The "step" command is what the code will "do next, atomically, then stop".
- The "continue" command (continue without stopping again) is what the code will "do next and thereafter".
- The "continue" command is the debugger's way to access a continuation.
- The Scheme function
call-with-current-continuationis like the "continue" command of this hypothetical debugger. - The difference is rather than having the debugger get access to the continuation, your code itself gets access to the continuation, "disguised" as a procedure rather than as a debugger command.
- Like any Scheme procedure, this "continuation procedure" can be called over and over again.
- Like any impure language, though, Scheme side effects like assignment and I/O are not purely functional and so subsequent invocations of the "continuation procedure" take place in the state of the system resulting from earlier side effects.
1 comment:
How about the web browser?
Hitting the back button a few times and navigating to another page is like calling with continuation.
In fact this is why continuations are so interesting because people use the "back" button in web applications as a way to perform undo, and server side applications have a hard time managing the users expectations.
Google for "Seaside" for more.
Post a Comment