<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
</head>
<body>
<div>There are no problems with reusability that I can think of as a result of the internal state machine.  The functions passed to `.then` are just plain functions, so they are perfectly reusable.</div>
<div><br>
</div>
<div>I don't think there is a significant overhead to promises once properly optimised.  I don't see how your solution would lead to lower overhead.</div>
<div><br>
</div>
<div>The state machine approach won't lead to race conditions in a multi-threaded environment because the promise state machine will always live on a single thread.  If JavaScript ever gets shared memory multi-threading it will be carefully restricted to prevent
 this kind of problem.</div>
<div><br>
</div>
<div>By contrast, systems built without a carefully engineered state machine (e.g. Thunks and your continuation based system) tend to lead to race conditions in user land code.  Once people try and write parallel code or caching/memoised using lazy continuation
 based systems they quickly end up needing to convert them into some kind of eager data structure.  This is often done badly (it's very difficult to get right) and can lead to very hard to debug race conditions.  By contrast, promises are very carefully designed
 and tested implementations of exactly this functionality.</div>
<div><br>
</div>
<div class="gmail_quote">_____________________________<br>
From: º«¶¬ <<a dir="ltr" href="mailto:handong05@meituan.com" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="0">handong05@meituan.com</a>><br>
Sent: Saturday, October 3, 2015 1:04 p.m.<br>
Subject: Re: Alternative to Promise<br>
To: Benjamin Gruenbaum <<a dir="ltr" href="mailto:benjamingr@gmail.com" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="3">benjamingr@gmail.com</a>><br>
Cc: <<a dir="ltr" href="mailto:es-discuss@mozilla.org" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="4">es-discuss@mozilla.org</a>><br>
<br>
<br>
<meta content="text/html; charset=utf-8">
<div class="">Hey Benjamin </div>
<div class=""><br class="">
</div>
<div class="">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? </div>
<div class=""><br class="">
</div>
<div class="">Here is my summary: </div>
<div class="">
<ul class="">
<li class="">Pros for state machine based solutions:
<ul class="">
<li class="">Auto memorization. </li><li class="">Easy sementics. </li></ul>
</li><li class="">Cons for state machine based solutions:
<ul class="">
<li class="">Bad reusability. </li><li class="">Larger overhead. </li></ul>
</li><li class="">Pros for continuation based solutions:
<ul class="">
<li class="">Good reusability, since continuation are just functions. </li><li class="">Lower overhead. </li></ul>
</li><li class="">Cons for continuation based solutions:
<ul class="">
<li class="">Complex sementics. </li><li class="">No memorization(can be done by other ways). </li></ul>
</li></ul>
</div>
<div class="">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?
</div>
<div class=""><br class="">
</div>
<div class="">Thanks again for giving me lots of detail about the history, now i need more : )
</div>
<div class=""><br class="">
</div>
<div>
<blockquote class="">
<div class="">On Oct 1, 2015, at 4:42 PM, Benjamin Gruenbaum < <a href="mailto:benjamingr@gmail.com" class="">
benjamingr@gmail.com</a>> wrote: </div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">
<div class=""><br class="">
</div>
> Where do you get the courage to challenge every inventor that they have to learn everything you've learned before they making decisions?
<div class=""><br class="">
</div>
<div class="">Can we please keep it civil? </div>
<div class=""><br class="">
</div>
<div class="">>  <span style="font-size:12.8px" class=""> </span> <span style="font-size:12.8px" class="">
the question is why not check other languages first, when there¡¯re nice solutions already there.</span>
</div>
<div class=""><span style="font-size:12.8px" class=""><br class="">
</span></div>
<div class=""><span style="font-size:12.8px" class="">Promises are rooted in the 1980s and have been pretty much adopted in every mainstream programming language one way or another:</span>
</div>
<div class=""><span style="font-size:12.8px" class=""><br class="">
</span></div>
<div class=""><span style="font-size:12.8px" class=""> - Task - C#</span> </div>
<div class=""><span style="font-size:12.8px" class=""> - Future - Scala</span> </div>
<div class=""><span style="font-size:12.8px" class=""> - Deferred - Python</span>
</div>
<div class=""><span style="font-size:12.8px" class=""> - CompletableFuture - Java</span>
</div>
<div class=""><span style="font-size:12.8px" class=""> - Future - C++</span> </div>
<div class=""><span style="font-size:12.8px" class=""> </span> </div>
<div class=""><span style="font-size:12.8px" class="">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 (<a href="http://blog.sigfpe.com/2008/12/mother-of-all-monads.html" class="">http://blog.sigfpe.com/2008/12/mother-of-all-monads.html</a>) 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.</span>
</div>
<div class=""><br class="">
</div>
<div class="">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. 
</div>
<div class=""><br class="">
</div>
<div class="">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. </div>
<div class=""><br class="">
</div>
<div class="">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. 
</div>
<div class=""><br class="">
</div>
<div class="">Cheers and good luck, </div>
<div class="">Benjamin </div>
</div>
_______________________________________________ <br class="">
es-discuss mailing list <br class="">
<a href="mailto:es-discuss@mozilla.org" class="">es-discuss@mozilla.org</a> <br class="">
<a dir="ltr" href="https://mail.mozilla.org/listinfo/es-discuss" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="10">https://mail.mozilla.org/listinfo/es-discuss</a>
<br class="">
</div>
</blockquote>
</div>
<br class="">
<br>
<br>
</div>
</body>
</html>