> > 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.
Yes, i also mentions this fact that javascript can use instanceof to dynamic choose fmap or >>= here: https://github.com/winterland1989/Action.js/wiki/Difference-from-Promise <https://github.com/winterland1989/Action.js/wiki/Difference-from-Promise>, the difference is that a Promise can’t be re-entered, while ConT can always be re-entered by runConT. > 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 exactly where i’m getting puzzled, suppose we have thread in javascript(or whatever to run different things on different cores), consider following code: var p = new Promise(…) // now on one thread we have p.then(func1) // on another thread p.then(func2) During pending stage, both func1 and func2 are going to pushed into an internal array, shouldn’t this array resize operation be protected by a lock? Thanks for your explanations. ~winter > On Oct 3, 2015, at 8: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 > <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] > <mailto:[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] >> <mailto:[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] <mailto:[email protected]> >> https://mail.mozilla.org/listinfo/es-discuss >> <https://mail.mozilla.org/listinfo/es-discuss> > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
