I’ve been pretty enamored of the “purely evented” approach of the Node.js framework. I remember the week that Ryah first announced Node, that it was going to have a really major impact on the way typical application developers would think about building network applications.

Having done a fair bit of it now and having read a lot of code in Javascript’s explicit continuation-passing style, I have to say there are some aesthetics of the style which can make things suboptimal from a readability standpoint.

1
2
3
4
5
6
7

store.getData(function (data) {
  store.getMoreData(data.id, function (more) {
    service.updateSomeData(more.id, function (update) {
      response.send(200, 'done.  update: '+update.code);
    })
  })
});

What if Javascript had a @= operator that macro-expanded the code to continuation-passing style under-the-covers, but would transform the nested syntax into the following:

1
2
3
4

var data   @= store.getData(@);
var more   @= store.getMoreData(data.id,@);
var update @= service.updateSomeData(more.id,@);
response.send(200, 'done.  update: '+update.code);

For this specific macro-expansion to work, the @ in the expression to the right of the @= operator denotes the place where the continuation function will be injected after the source is rewritten.

So basically within a { ... } any line using @= would treat following lines as code to embed in the callback.

1
2
3

var x = 1;
var data @= store.getData(@);
// REST-OF-CODE

1
2
3
4

var x = 1;
store.getData(function (data) {
  // REST-OF-CODE
})

But what if something goes wrong? Sometimes the async methods support error callback functions. How can we provide for these? What if the async functions yield multiple arguments instead of just the one?

Okay well I didn’t get that far. Just wanted to note this idea as a starting point. I’ll do that a lot on this blog.