与scalaz.concurrent.Future相比，scalaz.ContT有什么好处？

Question

我在寻找用于异步操作的数据类型。

我发现scalaz.ContT[Trampoline, Unit, ?]除了支持BindRec之外，还支持scalaz.concurrent.Future中的所有特性。

但是，scalaz.concurrent.Future的实用程序要比scalaz.ContT[Trampoline, Unit, ?]多，例如，应用实例并行运行期货。

我认为这些实用程序也可以为ContT[Trampoline, Unit, ?]实现。

作者为什么要创建一个新的Future-based scalaz-concurrent库而不是重用ContT？

Answer 1

冒着开玩笑的风险，一个关键的好处是，Future是一个命名的概念，很多人都会认可和理解，比如它有自己的维基百科页面。

我不认识ContT的类型，你说它是等价的。我试着在scalaz文档中找到它，但它是列在那里，没有任何解释。我在哪里能读到更多关于这方面的文章，你怎么知道它等同于未来？

您说“应用程序实例并行运行期货”；多个ContT操作不会并行运行吗？这是Futures的一个关键特性，并可能回答您的问题。

更新：

现在我看到ContT是延拓传递样式的实现，而scalaz.ContT[Trampoline, Unit, ?]是连续传递函数的特例，如果某些外部假设成立的话，该函数可能与Future同构。

我认为，你的问题的答案与许多其他特殊情况可能被认为是一个更普遍的结构的一个例子而得到突出的原因相同：

• 讨论更容易，命名也更容易。
• 它更有效，因为实现可以利用一般结构中可能不适用的一些特殊情况。
• 例如，我们可以确保Futures是并行执行的，而对于连续传递函数，我们一般不知道。(当然，可以像在一些测试框架中所做的那样，按顺序执行期货，但这不会被视为未来的常规实现)
• 它是一个有用的概念，它有利于程序员突出显示它并使其易于访问。