[Async methods] allow you to compose asynchronous stuff using normal flow of control and using all of the statements that you know already.

Pretty sweet. The first (longer) portion of the presentation is on the new asynchronous programming features for C# and VB. A hidden gem at the end (starting at timecode 50:40) is the “Compiler as a Service” status report. They’re experimenting with providing compiler front end, back end, and intermediate transformations as a run-time library.

It’s curious that there was no mention of the async transformations (first section) during his discussion of general purpose syntax transformations (second section). It would be interesting to see whether the “Compiler as a Service” libraries provide sufficient support as to be able to extend C# with things like ‘iterator syntax’ or ‘async methods’, without having to wait for a new compiler.

(A nod of course to Lisp’s macros, Scheme’s continuations, and Haskell’s use of monads; for defining new control flow primitives)

• 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.

Wow. Sun may have open-sourced Java in the past, but at this moment, the JVM seems like a more hostile platform than .Net.

For those who are curious which is the largest (island in a lake on an)^2 on an island. Because recursion isn’t just for programmers and computers.

Central to the thesis of FP is the notion of referential transparency.

Referential transparency leads to program compositionality.

// #1
X x = function();
R r1 = arbitrary(x);
R r2 = arbitrary(x);

// #2
R r1 = arbitrary(function());
R r2 = arbitrary(function());

If these two programs produce the same outcome then function is referentially transparent.

Well put. Back to the Reddit thread, functional programming and imperative programming are not a true dichotomy, but they one does need to mix carefully.

I find it most useful to build imperative programs on top a functional base, a foundation if you will. Taking the previous example, the function ‘arbitrary’ may not be a true function; it may modify persistent state, the values r1 and r2 being unequal. But building on top of the referentially transparent ‘function’, i can later refactor my program from #1 to #3:

// #3
void part1() {
R r1 = arbitrary(function()); /*...*/
}
void part2() {
R r2 = arbitrary(function()); /*...*/
}

And be able to rely on r1 and r2 being unchanged from their meaning in #1.

Referential transparency can be explained as the property that a function means the same thing every time you call it, no matter where or when you call it. That’s a very useful property to have in understanding and refactoring programs.