Fwd: Alternative to Promise

[韩冬]

> Begin forwarded message:
> 
> From: 韩冬 <handong05 at meituan.com>
> Subject: Re: Alternative to Promise
> Date: October 1, 2015 at 8:32:08 AM GMT+8
> To: "Tab Atkins Jr." <jackalmage at gmail.com>
> 
>> 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> 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
> 

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