Hey Benjamin

I want to know more about the implementation about Promise after two day of 
research, there’re two different ways of implementing a chain style control 
structure, one is based on an internal state machine, which save the callback 
for a moment, and resolve them after async function finish, the other one is 
based on continuation, every node on the chain are a new continuation contain 
the computation on the chain, some kind of porting the ConT monad from haskell 
to javascript, i’d like to compare them and get to know why the state-machine 
based solution eventually won?

Here is my summary:
Pros for state machine based solutions:
Auto memorization.
Easy sementics.
Cons for state machine based solutions:
Bad reusability.
Larger overhead.
Pros for continuation based solutions:
Good reusability, since continuation are just functions.
Lower overhead.
Cons for continuation based solutions:
Complex sementics.
No memorization(can be done by other ways).
Do you agree with me on this summary? and suppose in future javascript will get 
multicore support, will the state-machine based solution subject to race 
condition?

Thanks again for giving me lots of detail about the history, now i need more : )

> On Oct 1, 2015, at 4:42 PM, Benjamin Gruenbaum <[email protected]> wrote:
> 
> 
> > Where do you get the courage to challenge every inventor that they have to 
> > learn everything you've learned before they making decisions?
> 
> Can we please keep it civil?
> 
> >  the question is why not check other languages first, when there’re nice 
> > solutions already there.
> 
> Promises are rooted in the 1980s and have been pretty much adopted in every 
> mainstream programming language one way or another:
> 
>  - Task - C#
>  - Future - Scala
>  - Deferred - Python
>  - CompletableFuture - Java
>  - Future - C++
>  
> And so on and so on. The technical committee also includes people who 
> pioneered the concept. Practically everyone on this list knows Haskell, and 
> ConT isn't really anything new to any of us. We can all explore various 
> alternatives that are the continuation monad 
> (http://blog.sigfpe.com/2008/12/mother-of-all-monads.html 
> <http://blog.sigfpe.com/2008/12/mother-of-all-monads.html>) all day long - 
> but JavaScript already has continuations through promises and they are 
> already in the standard so there is absolutely zero chance they'll be 
> "swapped" for something else at this point.
> 
> There are about 3 years of discussions to read about the choices and the 
> rationale for why promises behave exactly the way they behave and you're 
> welcome to read those on the specific choices. 
> 
> If you're interested in current proposals for other async primitives for the 
> language - there is currently an observable proposal and an async iterator 
> proposal - both solve different issues than promises (multiple values over 
> push/pull) and are currently in design stages.
> 
> In general, the list frowns upon people who "plug their library" in the list 
> - so I suggest that in the future you start your email with the specific 
> problem you want to address and what you do differently. The more concise you 
> write (and external links aren't that great for this) the better chance 
> you'll get more responses from people involved. 
> 
> Cheers and good luck,
> Benjamin
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to