Continuation Style Without the Fugly

The previous post discussed advantages of using a continuation style to send our code to the data instead of making our code wait for the data to come back to it.

This pseudocode example has three I/O operations, each encasing the operations which should follow in a callback function parameter.

let filename = // calculate filename
new File(file).readAllLines().andThen( { data -> 
   // filter the data
   // summarize the data
   // reformat the data
   new File("output").writeAllLines(newData).andThen( { status ->
       println("done!")
       sendEmail("done! status = " + status).andThen( {
          println("email sent")
       })
   })
})

There’s an obvious negative here: it’s ugly. All this stuff happens in a clear sequence, the same sequence as in the first pseudocode, but it’s hard to see that with all those indentations.

It would be nice if we could describe this without all those curly braces and indentation.
F# async workflows are an example of that goal achieved. The following is pseudocode stuck in the middle of an F# async workflow block.

async {
  let filename = // calculate filename
  let! data = new File(file).readAllLines();
   // filter the data
   // summarize the data
   // reformat the output
   let! status = new File("output").writeAllLines(newData);
   println("done!");
   do! sendEmail("done! status = " + status);
   println("email sent");
} |> Async.Start

This is precisely what we’d like the code to look like, with a few exceptions. The “async” at the beginning and the piping of the block to Async.Start are the F# overhead to trigger the magic asynchronicity.
The let! and do! keywords are where the magic happens: they trigger F# to wrap the rest of the block into a super-sneaky callback that gets passed to an asynchronous operation which evaluates the expression in the let! or do! in another thread. When the file read is complete, the rest of the code proceeds, in whatever thread it’s in.

The second example executes exactly like the first one. But it reads sooo much more smoothly!

The tricky bit is that let! and do! sneakily break up the block of code. Anything after the let! may happen in a different thread, and then the next let! might switch execution to yet another thread. As a programmer we don’t have to worry about that, but it’s mind-bending when the code looks so sequential.

I hope we’ll see more languages and frameworks that can operate like this: pass the code to the data, but do so in a manner that keeps our code readable and organized.