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
>> [email protected]
>> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
