Tame.JS: Flow-control by the makers of OkCupid.com

I've been waiting for this sort of thing for the longest. The first time I saw the callback passed to a callback of a callback's callback style in Node.js, I wondered why the code couldn't look as nice as the async C++ I'd written at OkCupid. From my lips to Max &#38; Chris's minds... (telepathy!)<p>How long 'till the port to CoffeeScript syntax?

Ever since I first heard of CoffeeScript, I'd been hoping that features like this would make it into the language. It's not realistic to wait for javascript interpreters in the browser to catch up, but this would be a perfect addition for a compiler like CoffeeScript.

The problem this solves is a serious one, in my experience, even though I find their choice of syntax rather curious. Given that JavaScript 1.7 introduces the <i>yield</i> keyword, it would make sense to add support for that to V8 and implement the infrastructure for concurrent asynchronous I/O around that as a library. The concurrency aspect is, after all, orthogonal to the blocking vs. callback situation, and can easily be done even when using callbacks, with a single callback function called upon completion of all concurrent I/O. I believe the Dojo framework provides such a utility, and I wrote my own simplistic stand-alone mini-library for exactly this a while back. [0]<p>I've run into the problem of endless chained callbacks in C, where it's much worse due to the lack of nested functions, let alone closures or garbage collection.[1] I ended up using the switch block "coroutine" hack [2] for the worst cases, along with dynamically allocated "context" structs to hold "local" variables. A proper macro system would have helped transform blocking code into CPS form. I tried to integrate a SC [3] pass into our build, which could have done it, but ran into all sorts of practical/yak shaving problems, so I ended up with the C preprocessor macro/switch solution for now. In user space, explicit stack-switching with something like <i>swapcontext()</i> is probably preferable, if you can get away with it, but in the kernel this is rather problematic.<p>[0] <a href="https://github.com/pmj/MultiAsync-js" rel="nofollow">https://github.com/pmj/MultiAsync-js</a><p>The reason I wrote my own was because I originally needed it in Rhino, the JVM-based JS implementation, and I couldn't find anything similar that worked there.<p>[1] Yes, there are garbage collectors that work with C, but to my knowledge, none of them can be used in kernel modules. In any case, the other 2 issues are worse and aren't solveable within the language via libraries.<p>[2] <a href="http://www.linuxhowtos.org/C_C++/coroutines.htm" rel="nofollow">http://www.linuxhowtos.org/C_C++/coroutines.htm</a><p>[3] <a href="http://super.para.media.kyoto-u.ac.jp/~tasuku/sc/index-e.html" rel="nofollow">http://super.para.media.kyoto-u.ac.jp/~tasuku/sc/index-e.htm...</a>

Looks a lot like C# 5's await/async keywords:<p><a href="http://blogs.msdn.com/b/ericlippert/archive/tags/async/" rel="nofollow">http://blogs.msdn.com/b/ericlippert/archive/tags/async/</a><p>Cool to see growing interest for this at the language level.

I've been very happy with "parallel" in the async library by caolan <a href="https://github.com/caolan/async" rel="nofollow">https://github.com/caolan/async</a>

Why hasn't anyone brought up error handling yet? What happens when an error is thrown inside a twait block? What happens when 2 errors are thrown inside a twait block?<p>Tame.js looks nice in that it's very simple to learn but ~300 lines of plain old JavaScript[1] can give you a general purpose deferred/promise library with more flexibility should you need to do something other than wait on N async operations and then use the results.<p>[1] <a href="https://github.com/heavylifters/deferred-js/blob/master/lib/deferred.js" rel="nofollow">https://github.com/heavylifters/deferred-js/blob/master/lib/...</a>

In what significant ways is this different from deferreds/promises/futures?

This seems neat, but after reading through it twice I can't seem to understand how this provides any advantage over just using Deferreds. Someone care to enlighten me?

That reminds me of monads in Haskell (they can solve this problem (and other as well) matemagically). I've seen somewhere a proposal to add them into Javascript, but I doubt the idea will be loved by public.<p>(By "add them to JS" I mean some syntactic sugar, not a library)

This is the wrong solution to the problem, and it's implemented poorly.<p>Use a proper control-flow ( not "flow-control" ) library like <a href="https://github.com/caolan/async" rel="nofollow">https://github.com/caolan/async</a>.<p>Furthermore, why would you write an entire custom js parser for this? Why not use some of the many many pre-existing ones that are much more stable, more developed, and well supported.

Slightly Unrelated: There was a site recently on hn that was a listing of various js libraries, like this one, on one page. What was it?

This is nice on the browser, but not very useful in nodeJS.<p>twait{} will block and stop my nodeJS process from doing anything else.<p>It would be more useful if I could give twait{} a callback to fire when all its async events completed. Then my nodeJS process could do other stuff while waiting for a twait{} bundle to finish.

Also see JSCEX, which uses the C# keyword await<p><a href="http://groups.google.com/group/nodejs/browse_thread/thread/337f83c028f371c2" rel="nofollow">http://groups.google.com/group/nodejs/browse_thread/thread/3...</a>

The next version of Visual Studio will have something similar: <a href="http://msdn.microsoft.com/en-us/vstudio/async.aspx" rel="nofollow">http://msdn.microsoft.com/en-us/vstudio/async.aspx</a>

So the code we write is clean and easy to understand, but the debugger only work with the compiled version of the code?<p>In another word, write in C, and debug in assembly...

There's a bug in huntMen. <i>if (! is_vamp)</i> should instead be <i>if ( is_vamp)</i>... :P

why not just use node-fibers?

For those who looking for the JavaScript way of the examples; <a href="https://gist.github.com/1090228" rel="nofollow">https://gist.github.com/1090228</a>