Alternative to Promise
benjamingr at gmail.com
Sat Oct 3 12:17:32 UTC 2015
The state machine solution is not susceptible to race conditions. If you
care about the roots of what promises were originally designed for, you
might want to start with Mark's work at:
I'm not sure why you'd look at promises as a state machine solution, it's
really just a proxy for a value, the way a IO monad in Haskell wraps a
value in an IO operation - a promise wraps a value in an async operation in
Promises also do two more things - they cache the value and dispatch `then`
handlers asynchronously. Both these things exist to prevent race conditions
where you subscribe to a promise after it resolves which would otherwise
create race conditions.
This is not a complex state machine, it's a very simple unidirectional flow
graph where you transition from "Pending" to either "fulfilled" or
"rejected" and I can draw a similar "state machine" for callback based
solutions (even a ConT port).
A continuation at its core is just a callback that also happens to signal
that a function has completed. There is nothing inherently clever about a
continuation - a promise _is_ kind of a continuation monad. In fact, if you
look at promises, apart from the fact `.then` does both `map` and `bind`
(flatMap here) it _is_ the continuation monad, had the monadic-promises
camp one and we would have gotten `.chain` instead of `.then` (still in
Chrome BTW) we could have formally said promises are an instance of a
Also note that promises are really fast, if you look at bluebird 3 promises
for instance - creating a promise takes less slots than an empty array and
you can create a million ones concurrently without any issues. In fact,
oftentimes the way people code uses closures which tend to be more
expensive than creating promises anyway.
On Sat, Oct 3, 2015 at 3:04 PM, 韩冬 <handong05 at meituan.com> wrote:
> 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
> 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).
> 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 <benjamingr at gmail.com>
> > 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) all day long -
> 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,
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss