一流的延续

Question

对于将继续作为第一类对象暴露的一些批评是什么？

我觉得有一流的延续很好。它允许完全控制指令的执行流程。高级程序员可以针对某些类型的问题开发直观的解决方案。例如，continuation用于管理Web服务器上的状态。语言实现可以在延续之上提供有用的抽象。例如，绿色线程。

尽管有这些，是否有强烈反对头等延续的论据？

Answer 1

现实情况是，许多可以使用continuation的有用情况已经被专门的语言结构所涵盖：throw / catch，return，C＃/ Python yield。因此，语言实现者实际上并没有那么大的动力来提供可用于自己动手解决方案的通用形式。

在某些语言中，广义延续很难有效实施。基于堆栈的语言（即大多数语言）基本上必须在每次创建延续时复制整个堆栈。

这些语言可以实现某些类似延续的特性，那些不会破坏基本的基于堆栈的模型，比一般情况更有效，但实现广义延续是相当困难的，不值得。 / p>

由于以下几个原因，函数式语言更有可能实现continuation：

1. 它们经常以连续传递方式实现，这意味着“调用堆栈”可能是在堆上分配的链表。这使得将指针作为延续传递给堆栈变得微不足道，因为当您弹出当前帧并推送新帧时，不需要覆盖堆栈上下文。 （我从未实施过CPS，但这是我对它的理解。）
2. 他们喜欢不可变数据绑定，这使得旧的继续更加有用，因为你不会改变堆栈在创建它时指向的变量的内容。

由于这些原因，延续可能主要仅限于功能语言领域。

Answer 2

首先，当谈到延续时，还有更多的呼叫/ cc。我建议从Mark Feelys论文开始：A better API for first class continuations

接下来我建议阅读有关控制操作员移位和重置的信息，这是表示收缩的一种不同方式。

Answer 3

重大异议是实施成本。如果运行时使用堆栈，那么第一类continuation在某些时候需要堆栈副本。可以控制复制成本（有关良好策略，请参阅Representing Control in the Presence of First-Class Continuations），但这也意味着无法在堆栈上分配可变变量。这对于功能性或功能最强大的（例如，Scheme）语言来说不是问题，但这会为OO语言增加大量开销。

Answer 4

1. 大多数程序员不理解它们。如果你有使用它们的代码，那么很难找到能够使用它的替代程序员。
2. 在某些平台上难以实现延续。例如，JRuby不支持continuation。

Answer 5

一流的延续破坏了推理代码的能力，特别是在允许将变量强制分配给变量的语言中，因为闭包的内部可以以毛茸茸的方式再次活跃起来。

比照。 Kent Pitman's complaint about continuations，关于unwind-protect与call / cc

交互的棘手方法

Answer 6

Call / cc是高级函数式编程的'goto'（例如here）。

Answer 7

在ruby 1.8中，实现速度非常慢。在1.9中更好，当然大多数方案已经内置并且从一开始就表现良好。