PS To be concrete, here's an example code snippet using my jstask library that chains several event-generated actions together in a natural way (i.e., in direct style, i.e. not in CPS):
var task = new Task(function() { var request = new HttpRequest(); try { var foo = yield request.send(this, "foo.json"); var bar = yield request.send(this, "bar.json"); var baz = yield request.send(this, "baz.json"); } catch (errorResponse) { console.log("failed HTTP request: " + errorResponse.statusText); } ... foo.responseText ... bar.responseText ... baz.responseText ... }); I should also point out that the core of jstask is 7 lines of code. :) Dave On Dec 9, 2010, at 7:55 AM, David Herman wrote: > I pretty much abandoned that line of investigation with the conclusion that > generators: > > http://wiki.ecmascript.org/doku.php?id=strawman:generators > > are a good (and well-tested, in Python and SpiderMonkey) design for > single-frame continuations. They hang together well; in particular, they > don't have the issues with `finally' that some of the alternatives I talked > about do. Moreover, the continuation-capture mechanisms based on call/cc or > shift/reset require additional power in the VM to essentially tail-call their > argument expression. When I tried prototyping this in SpiderMonkey, I found > this to be one of the biggest challenges -- and that was just in the > straight-up interpreter, not in the tracing JIT or method JIT. > > Generators work well for lightweight concurrency. As a proof of concept, I > put together a little library of "tasks" based on generators: > > http://github.com/dherman/jstask > > Somebody reminded me that Neil Mix had written a very similar library several > years ago, called Thread.js: > > http://www.neilmix.com/2007/02/07/threading-in-javascript-17/ > > and there's another library called Er.js that built off of that to create > some Erlang-like abstractions: > > http://www.beatniksoftware.com/erjs/ > > Dave > > On Dec 8, 2010, at 11:36 PM, Tom Van Cutsem wrote: > >> The spirit of the proposal is that this special type of statement be a >> linear sequence of function executions (as opposed to nested >> function-reference callbacks delegating execution to other code). >> >> The special behavior is that in between each part/expression of the >> statement, evaluation of the statement itself (NOT the rest of the program) >> may be "suspended" until the previous part/expression is fulfilled. This >> would conceptually be like a yield/continuation localized to ONLY the >> statement in question, not affecting the linear execution of the rest of the >> program. >> >> This reminds me of a proposal by Kris Zyp a couple of months ago ("single >> frame continuations") >> https://mail.mozilla.org/pipermail/es-discuss/2010-March/010865.html >> >> I don't think that discussion lead to a clear outcome, but it's definitely >> related, both in terms of goals as well as in mechanism. >> I also recall it prompted Dave Herman to sketch the design space of >> (single-frame) continuations for JS: >> https://mail.mozilla.org/pipermail/es-discuss/2010-April/010894.html >> >> Cheers, >> Tom >> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss