Alternative to Promise

[韩冬]

> 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?

> 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.



> On Oct 1, 2015, at 8:25 AM, Tab Atkins Jr. <jackalmage at gmail.com <mailto:jackalmage at gmail.com>> wrote:
> 
> On Wed, Sep 30, 2015 at 5:18 PM, 韩冬 <handong05 at meituan.com <mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151001/eb3a5df3/attachment.html>