Claus Reinke claus.reinke at
Wed Nov 7 01:18:34 PST 2012

> Why not task.js, instead?

1. Implementation complexity

    let-from: trivial syntax transformation

    task.js+generators: non-trivial syntax transformation or
        -more likely- non-trivial runtime system manipulation

2. Usage complexity

    let-from: just another statement in the block,
        merely syntax for conventional promise/callback-style

    task.js+generators: spawn+function*+yield,
        complex rts + complex library

3. Usage granularity

    let-from: statement level

    task.js+generators: function level

Note that the trade-offs are not entirely against task.js: because JS
has so much non-overridable surface syntax, it is useful to have the
pre-packaged functionality of generators built-in, and it is useful to
reuse that functionality for async and co-routine code, via task.js.
As long as you use it to wrap non-trivial segments of code.

But when you don't want to deal with code that uses while/for/if/..,
or if you want to build up your code patterns from smaller
components, then let-from has advantages. For let-from to fully
replace task.js and generators, JS would need library-based
control structures or overridable control-structure syntax (eg,
Haskell monads or F# computation expressions).


> Different issue: do we already have a solution for a missing error handler causing silent 
> failures? task.js should cover this, too (right?)
> [[[Sent from a mobile device. Please forgive brevity and typos.]]]
> Dr. Axel Rauschmayer
> axel at
> Home:
> Blog:
> On 07.11.2012, at 00:42, "Claus Reinke" <claus.reinke at> wrote:
>>> I agree that promises should be standardized in Ecma-262.
>> Agreed. That would also offer the possibility to support promises
>> in syntax. In ES7 (latest), I would like to see something roughly like
>>   { ...;
>>     let x <- promise;
>>     ...;
>>   }
>> (read as "let x from promise"), desugaring into
>>   { ...;
>>     promise.then( (x) => { ...; };
>>   }
>> Essentially, this is an even shallower continuation than generators
>> (only the remaining statements in the current statement list), but it
>> is already sufficient to avoid callback nesting issues in async code. It also suffices to 
>> implement generators, but for syntax.
>> By relying on nothing but a '.then' method, this isn't tied to promises
>> in the narrow sense, but provides a reusable building block for other control abstractions (to 
>> begin with, abstracting away the default
>> error handling in some APIs).
>> Claus
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at


More information about the es-discuss mailing list