Alternative to Promise

[Thomas]

>> There's only one variation that's standard, and every browser is or
>> will soon be implementing that one.
> 
> How can you said so? isn’t every Promise library pass A+ test considered standard?

There is a specific variation of promises in the ECMAScript standard which is compatible with promises/a+. Passing the tests simply means your implementation of promises is compatible.

>> Continuations are a different concept, and don't address what we were
>> trying to solve when adopting promises.
> 
> Yes, they’re different, i would like to know what is promise solved but they didn’t address ?
> 
>> Those languages often also have Promises, or Futures, or Tasks, or one
>> of the other closely-related names and concepts.
> 
> They have, but that’s totally different because they use lightweight thread. Future in haskell is just a MVar.

If the filesystem API in node.js starts to use promises then it would be using a background thread, just as it is doing for callbacks at the moment.

>> On Oct 1, 2015, at 8:25 AM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
>> 
>>> On Wed, Sep 30, 2015 at 5:18 PM, 韩冬 <handong05 at meituan.com> wrote:
>>> Yes, i understand it’s too late to revise Promise design, my random thought are:
>>> 
>>> 1. Why we put Promise into language?
>> 
>> Because it exposes useful functionality.  I recommend reading some of
>> the Promise explainers that exist for lots of examples.
>> 
>>> Promise are complex state machine, there can be so many variations, each implementation have different performance characteristic, which one should be built into language?
>> 
>> There's only one variation that's standard, and every browser is or
>> will soon be implementing that one.
>> 
>> The "state machine" isn't complex.  "unresolved" goes to either
>> "resolved to another promise", "fulfilled", or "rejected".  "resolved
>> to another promise" eventually turns into "fulfilled" or "rejected".
>> Or, of course, hangs, which "unresolved" can also do.
>> 
>>> 2. Why we don’t look for continuation based implementation at the first place?
>> 
>> Continuations are a different concept, and don't address what we were
>> trying to solve when adopting promises.
>> 
>>> Lisp, haskell or even some transpiled to js language like elm use continuation solve callbacks already, why didn’t port them?
>>> Now we invent a complex state machine based solution, a lot of people will creating them everytime using an `async` without understand the cost.
>> 
>> Those languages often also have Promises, or Futures, or Tasks, or one
>> of the other closely-related names and concepts.
>> 
>> ~TJ
> _______________________________________________
> 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/20151001/bcd26da9/attachment.html>