• Continuation Passing Style Revisited, Part One.
• Continuation Passing Style Revisited Part Two: Handwaving about control flow.
• Continuation Passing Style Revisited Part Three: Musings about coroutines.
• Continuation Passing Style Revisited Part Four: Turning yourself inside out.
• Continuation Passing Style Revisited Part Five: CPS and Asynchrony.

I bet part 2 will cover exception handling. That, or call/cc, then EH in part 3. We’ll see

Update (10/22): Yay, I was right, EH is up next.  He also writes “Next time: handwaving about coroutines”.  I’m sure call/cc will be in part 3.

Update (10/25): Part 3 is up — skips call/cc (makes sense, as Eric it talking about writing CPS explicitly) moving straight to one application of CPS: coroutines. Ominiously ends with “Next time: if Continuation Passing Style is so awesome then why don’t we all use this technique every day?” Presumably he will be talking about the specific implementation technique he’s chosen, as various runtime environments (usually Scheme implementations) *do* use CPS for compilation all the time, and a few do so with no ill effect.

Update (10/27): Part 4 and 5 are up.  Part 4 notes that CPS is generally *hard* to understand for most folks, but that CPS is ultimately general purpose, making for quick implementation of a wide variety of programming language control flow constructs.

Part 5 further talks about the explicit use of CPS in designing asynchronous programming APIs. I’m somewhat disappointed that Eric skips over the CPS to model for loops, instead resorting to a state machine like the C# compiler uses when compiling iterator syntax. It’s a fine implementation technique, but it seems like a missed opportunity to me, and it would have avoided the “definite assignment problem” he mentioned. And lastly, while the invocation of the continuation was straightforward in CPS, a lot of synchronization work has been glossed over in ‘SetContinuation’ — the continuation may not always be ready by the time that ‘AsyncFetch’ goes to invoke it. This seems unnecessarily wasteful, as the caller always knows the continuation they’re about to set — the caller code is simplified only by reordering, at the expense of runtime cost and added complexity in AsyncFetch.

I think the switch to use ‘SetContinuation/GetResults’ is done too early. It makes it easier to connect his example to .Net’s Task Parallel Library, but now there isn’t a single example in direct CPS style that demonstrates asynchrony.

I’m only so critical of Part 5 as I think Eric Lippert has done quite well in the rest of this series. To be balanced, many programmers will find the state machine model easier to read. As a CPS topic, I find Part 5 lacking; It shines as an explaination of asynchrony in .Net.  It a very good piece, but is an ugly duckling in a CPS series.

Again, I appreciate his work here.  Please take the time to give this series a read.

The talk actually had one direct and important consequence for computing. Under the inspiration of the notion of the unnecessity of goto’s, Dijkstra spent that evening constructing realistic examples of programs without goto’s, … So while van Wijngaarden said that goto’s were unnecessary … , Dijkstra stretched the point to say that goto’s were inconvenient. The latter lesson stuck. — McIlroy

The continuation passing transformation grew out an attempt to formalize GOTO, and ended up both obsoleting it as well as producing new, better structured control primitives (for example, break).  It’s strange to me that I could have gone as far as I have, as a programmer, without having a good understanding of this concept. We use it implicitly all the time — the call stack of course — but rarely consider all of the ramifications (threading) and certainly not all of the utility (coroutines, exception handling, etc).

Erik Lippert writes (and again) on C# loop variable closure semantics. The confusion arises because a “foreach” loop’s iteration variable is not assignable in C# — which leads the programmer to think it is constant — but actually it is variable, getting re-bound each iteration to the next item in the sequence.  This normally wouldn’t matter much, but if you have a lambda that closes over that loop variable, the lambda will observe the re-bindings each iteration.

While searching for Haskell blogs, found this interesting response by one Adam Turoff.  He mentions Ruby, JavaScript, and Scheme, but especially Haskell.  He points out quite rightly that, in pure functional code, capturing a reference or copy is indistinguishable due to referential equality.  C# was very close to getting this right — it prevents the user from rebinding the variable, but the real error was forgetting to prevent itself from doing the same.

However, the compiler isn’t really implementing a loop variable, it’s actually thin syntax over the .Current property of the iterator.  The ‘foreach’ loop aims only to expose the CLR iterator pattern, so it makes sense that it would remain as close to it as possible.  Another possible explanation: the real error was allowing the programmer to close over a variable that wasn’t really a variable.