natively negotiating sync vs. async...without callbacks

[David Herman]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20101209/20a3b4db/attachment.html>