scala - 什么时候使用来自 scalaz 的 monad？

Question

我想为计算创建一个简单的包装器。内置的 scala monads (TraversableLike) 对我来说似乎足够了。他们已经有了语法糖。从某些角度来看，scala 集合特征是偶然的单子(monad)。 scalaz 库提供了预期的 monad。

哪些用例受益于 scalaz 的复杂类型分类 monad？哪些功能对于内置 monad 不可行并表明需要 scalaz？

---

一些说明。

这道题不是圣战继承vs类型类。我的问题是关于提供 scalaz 的基础设施。不是任何具有类型类方法的库，而是这个提到的库。它使事情稍微复杂化。但它也有一堆在 scala 集合库中没有匹配的实用程序类。因为它是一个集合库，而不是一个 monadic。所以问题是关于 scalaz 提供的附加功能。在哪些情况下重要？

Answer 1

首先是关于术语的一点:有时像“Option 是一个单子(monad)”这样的速记是很有用的，但是“Option 有一个单子(monad)实例”或“Option 是单子(monad)”更清楚。说 Scalaz 提供了一堆 monad 可能有点令人困惑——它提供的是 Monad。许多类型的类型类和该类型类的实例，包括它自己的一些(例如 \/ 、 Task 等)和标准库中的一些( List 、 Option 等) .

所以我将回答一个与您的问题类似的问题:显式 Monad 的值(value)是什么？在标准库提供的 monadic 语法糖上键入类？

有一个显式 Monad 的地方当你想定义你自己的通用组合器或操作时，representation 很有用。假设我想写一个方法 addM这需要两个 monadic M[Int]值并将它们添加到 monad 中。 Option 很容易写:

def addM(oa: Option[Int], ob: Option[Int]): Option[Int] = for {
  a <- oa
  b <- ob
} yield a + b

或者对于列表:

def addM(oa: List[Int], ob: List[Int]): List[Int] = for {
  a <- oa
  b <- ob
} yield a + b

这两个实现显然有很多共同点，如果能够编写一个适用于这两种情况并适用于任何其他 monadic 类型的单一通用实现，那就太好了。如果我们只有标准库的手波式 monadic 语法，这真的很难，如果我们有 Monad 就真的很容易。类型类。