HE Shi-Jun

@bakkot I guess this issue could be adjusted to using `const x = (let x = Math.random(); x * x)` instead of `const x = do { let x =...

> It also gets really complicated with object literals Great example! I always caught by object literals vs block statement :)

I believe they are same, so yes I think we should rename `LastYieldValue` to `ReceivedValue`. But `resumptionValue` name is ok because it's for the sender side.

Dropping the first `next` is always a workaround, actually this is very close to what babel transformer do. I don't like to add a new kind of function, but I...

How modifying a class metadata causing all "sibling" subclasses metadata changed would be "correct behavior"?

I suppose conditional creating metadata object is mainly for perf, but consider this footgun I feel we should always create metadata for subclasses. I guess engines could optimize such thing,...

@island205 本文其实主要是献给 @zensh 的。我认为说问题不在于重造轮子，或者搭帝国是不是现实的问题，而是方案本身的优劣。thunk和promise其实本质是一样的，本文希望解释清楚在本质一样的前提下，为什么promise比thunk好。 @jiyinyiyong 按我理解，在纯函数式语言中，异步不是大问题，因为没有副作用，执行先后顺序没关系。

1. 你还没有搞明白releasing zalgo的害处。我最近因为要准备css conf，所以暂时没时间写例子了。但是还是希望可以再读读isaac那篇文章体会一下。注意问题不是受不受影响，而是thunks本身现在就是releasing zalgo的。你注意，promise就不会releasing Zalgo，promise.resolve(x).then(f)，这个f一定是异步执行的。为什么promise标准要这样，为什么node的api文档也特别强调了这一点，你需要好好考虑下。（虽然很多人不注意node其实有这个要求——这正好是node的一个缺点，因为callback无法确保这一点，只能靠文档强调和自觉，而promise从基础上确保了这一点。） 2. max call stack size exceeded跟releasing zalgo没有直接关系（因为顶楼是一个提纲，所以也许表达的不够清楚）。本身这不是一个编程模式上的问题，而是实现上的不足。从某种角度说可归咎为js语言没有尾递归优化导致的问题。解决方法其实你看看bluebird或when的实现即可（具体说看when里的scheduler的实现和用途）。注意thenjs.series之类的api之类只能处理在调用时就已确定一系列处理过程的情况，所以不能解决问题本身。测试代码只是方便而写成了这样，实际上是不能用then.series解决的。 3. 原生promise本身异步流程管理能力不够。这一点我是赞同的。但是标准只是把最核心的部分做掉。而整个异步管理中最最最重要的是什么？其实我顶楼已经总结了，就是语义本身的清晰（thunks在这点上恰好是反例）。此外的utils都是不难实现的，没有必要在标准库里包含，或者可等到大家有更多共识再标准化（目前只提供了promise.all和promise.race）。另外注意认为原生promise有debug问题是不对的，去看看chrome canary上的原生promise对调试的支持你就知道了，这是native promise的优势而不是劣势。 4. thunk并不立即执行，这点我之前还没意识到——这正好也说明语义不清晰的问题，我不知道有多少人看了api接口后会意识到这点。另外这是否是大部分人编程中想要的行为？注意，我们不能笼统的说惰性求值是好的，因为在一个本身极少见惰性求值的语言中，以这样一种无法从调用api上分辨是否惰性的方式来引入惰性求值，并作为基础编程模式，是值得斟酌的。顺便注意co在使用thunk时并不会利用到惰性这一点，因为它yield一个thunk之后这个thunk就执行了。 5. ES7 async/await不可能支持thunk。因为thunk不是标准。而thunk为什么不是标准？因为它不如promise。为什么不如？就是我之前讲的那些点。 6. thunks能处理promise，也能处理thunk或其他东西，这谈不上是优点。我们根本没有必要组合一切异步方式，当promise成为标准，我们只需要promise这唯一的异步原语而已。比如co 4转向promise，它还支持thunk只是保持向后兼容而已。其他类似co的库就不支持thunk而只支持promise。 7. nodejs的api不可能输出thunk。它唯一的可能是走向输出promise，尽管现在核心开发者还是对此持保守态度。这一判断的根据其实无需多言。 8. then多次调用是一个非常明显的需求，比如 http://weibo.com/2041028560/BE0R1tgpt...

@jiyinyiyong @undoZen 的意思是，扔给thunk的函数只是为了通过调用它而继续执行，而不是用来求值的。而promise则相反。因为异步被包到了promise内部，所以在外部看来promise是一个可反复使用的值，可以被传递给纯函数。这就是promise是monad的意思。

@jiyinyiyong 他的意思是返回promise的函数可以把副作用包在promise里面，所以本身可以是纯的。