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 <[email protected]> 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, 韩冬 <[email protected]> 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 <[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) 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 > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
