It’s just data
Frankly, I’m surprised how much interest Continuations for Curmudgeons generated. I guess that there was a demand for an explanation from the perspective of a C programmer, eh?
Based on two bugs reported in one section, I’ve updated it to reflect that what is being described there is actually a closure, not a continuation. I’ve also added a section showing how classes are simply a special case of closures.
Your description is a little more down-to-earth than most I’ve seen. I can understand popping references off the stack when a function returns. Most other explanations of continuations are just a bit more abstract and harder to connect with something I already get.
I still don’t grok them, but I think I understand them a little more now.
Posted by Dougal Campbell atI’ve been doing a lot of non-blocking I/O development these days, and I think, but I’m not sure, that this is the solution to a problem I’ve been trying to solve.
Using typical stack based programming it is required to “rebuild the stack” every time you process more data on a connection from the OS.
This is typically done with state machines. These machines can quickly get out of control, and I suspect my current project has hundreds of states when all the sub-machines are added up.
If this can be generalized for non-blocking I/O it might radically change the way web apps are developed.
Posted by christopher baus at[link]...
Excerpt from del.icio.us/mmower/programming at