Alternative to Promise

Sat Oct 3 15:00:33 UTC 2015

well

> In fact, oftentimes the way people code uses closures which tend to be
more expensive than creating promises anyway.

you pass "closures" to create a promise, a then and  a catch, not sure what
you mean here.

The Promise  itself cannot be counted without counting the amount of
middle-callbacks needed to make it work, right? Am I misunderstanding that
sentence?

On Sat, Oct 3, 2015 at 2:17 PM, Benjamin Gruenbaum <benjamingr at gmail.com>
wrote:

> 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:
> http://www.erights.org/talks/thesis/markm-thesis.pdf
>
> 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
> JavaScript.
>
> 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
> continuation monad.
>
> 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
>> 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 <benjamingr at gmail.com>
>> 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) 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
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>>
>
> _______________________________________________
> 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/20151003/848b86e0/attachment-0001.html>