一流延续的缺点
针对将延续暴露为第一类对象提出了哪些批评？
我觉得有一流的延续很好。它允许完全控制指令的执行流程。高级程序员可以为某些类型的问题开发直观的解决方案。例如，延续用于管理 Web 服务器上的状态。语言实现可以在延续之上提供有用的抽象。例如，绿色线程。
尽管如此，是否有强烈的理由反对继续一流的课程？
What are some of the criticisms leveled against exposing continuations as first class objects?
I feel that it is good to have first class continuations. It allow complete control over the execution flow of instructions. Advanced programmers can develop intuitive solutions to certain kind of problems. For instance, continuations are used to manage state on web servers. A language implementation can provide useful abstractions on top of continuations. For example, green threads.
Despite all these, are there strong arguments against first class continuations?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
现实情况是，许多可以使用延续的有用情况已经被专门的语言结构所涵盖：抛出/捕获、返回、C#/Python 产量。因此，语言实现者实际上并没有太多的动力以可用于推出自己的解决方案的通用形式提供它们。
在某些语言中，广义延续很难有效地实现。基于堆栈的语言（即大多数语言）基本上必须在每次创建延续时复制整个堆栈。
这些语言可以实现某些类似延续的功能，这些功能不会破坏基于堆栈的基本模型，比一般情况更有效，但实现通用延续要困难得多，而且不值得。
函数式语言更有可能实现延续，原因如下：
由于这些原因，延续很可能主要停留在函数式语言领域。
The reality is that many of the useful situations where you could use continuations are already covered by specialized language constructs: throw/catch, return, C#/Python yield. Thus, language implementers don't really have all that much incentive to provide them in a generalized form usable for roll-your-own solutions.
In some languages, generalized continuations are quite hard to implement efficiently. Stack-based languages (i.e. most languages) basically have to copy the whole stack every time you create a continuation.
Those languages can implement certain continuation-like features, those that don't break the basic stack-based model, a lot more efficiently than the general case, but implementing generalized continuations is quite a bit harder and not worth it.
Functional languages are more likely to implement continuations for a couple of reasons:
For these reasons, continuations are likely to remain mostly just in the domain of functional languages.
首先，当涉及到延续时，除了 call/cc 之外还有更多内容。我建议从 Mark Feely 的论文开始：A better API for First Class Continuations
我建议阅读有关控制运算符移位和重置的内容，这是表示连续的不同方式。
First up, there is more then just call/cc when it comes to continuation. I suggest starting with Mark Feelys paper: A better API for first class continuations
Next up I suggest reading about the control operators shift and reset, which is a different way of representing contunations.
一个重要的反对意见是实施成本。如果运行时使用堆栈，则一流的延续在某些时候需要堆栈副本。复制成本是可以控制的（参见在存在一流的情况下代表控制延续是一个好的策略），但这也意味着可变变量不能在堆栈上分配。对于函数式或主要函数式（例如，Scheme）语言来说，这不是问题，但是对于 OO 语言来说，这会增加大量开销。
A significant objection is implementation cost. If the runtime uses a stack, then first-class continuations require a stack copy at some point. The copy cost can be controlled (see Representing Control in the Presence of First-Class Continuations for a good strategy), but it also means that mutable variables cannot be allocated on the stack. This isn't an issue for functional or mostly-functional (e.g., Scheme) languages, but this adds significant overhead for OO languages.
一流的延续削弱了推理代码的能力，特别是在允许将延续强制分配给变量的语言中，因为闭包的内部可以以毛茸茸的方式再次活跃起来。
比照。 Kent Pitman 对延续的抱怨， unwind-protect 与 call/cc 交互的棘手方式
First-class continuations undermine the ability to reason about code, especially in languages that allow continuations to be imperatively assigned to variables, because the insides of closures can be brought alive again in hairy ways.
Cf. Kent Pitman's complaint about continuations, about the tricky way that unwind-protect interacts with call/cc
Call/cc 是高级函数式编程的“goto”（例如此处 ）。
Call/cc is the 'goto' of advanced functional programming (a la the example here).
在 ruby 1.8 中，执行速度非常慢。 1.9 中更好，当然大多数方案都内置了它们，并且从一开始就表现良好。
in ruby 1.8 the implementation was extremely slow. better in 1.9, and of course most schemes have had them built in and performing well from the outset.