为什么 Haskell 的仿函数上没有幺半群的类型类？答案

【问题标题】：Why is there no type class for monoids on functors in Haskell?为什么 Haskell 的仿函数上没有幺半群的类型类？
【发布时间】：2015-04-15 14:41:02
【问题描述】：

我承认这个问题有点不具体，但我想知道为什么我从来没有在 Haskell 的仿函数上偶然发现一个类型类。我是否只是错过了它，这种缺席是否有充分的理由，或者完全是由于历史原因？恕我直言，没有右上角的继承图看起来有点奇怪：

  Functor
     |
     V
Applicative ––> Alternative
     |               |
     V               V
   Monad    ––>  MonadPlus

【问题讨论】：

您可以随时添加它（如果可以合理定义，可能有一些 CT 库可以这样做） - 我最好的猜测：那里没有/不够用例
我不同意你总是可以添加它，因为你不能让它成为 Alternative 的超类。我还认为（几乎）Alternative/MonadPlus 的每个用例实际上都是这个缺失类的用例。但也许我在这里有点太理想化了。
Monoid 课程不是已经涵盖了这个吗？您能否详细说明您认为该课程应该具有哪些方法超出Monoid 已经提供的方法？

标签： haskell typeclass functor monoids alternative-functor

【解决方案1】：

这里要考虑的一个关键因素是，“Functor 中的箭头到底是什么意思？”如果没有将Functor 与FunctorPlus 统一起来的公理，那么您不妨定义instance Monoid (F t) where ... 并完成它。那么你在寻找什么公理——只是fmap f fempty = fempty 或fmap f x <|> fmap f y == fmap f (x <|> y)...？

另一个关键因素是缺乏有趣的结构，它们是函子而不是应用程序。可能有一个与泛型编程（元编程 deriving 关键字）有关的论点，其中一切都是乘积的总和，因此我们可以为任何类型的 * -> * 推导出 Applicative，但我不知道细节. FunctorPlus 可能具有的唯一价值是“与 Alternative 对非 Applicative 的 Functor 所做的事情相同”，因此如果该集合非常小，那么显然没有多少附加值。

【讨论】：

我不同意你的假设，即非应用函子不相关。即使应用实例可能，它通常既不明显也不真正有用。而Functor 实例始终是规范的——如果可能的话，那么它的行为就不会有歧义，并且可以通过-XDeriveFunctor 实例自动添加该实例。
@leftroundabout 我同意你的不同意见。从某种意义上说，这是一个答案，“这可能是尚未完成的一些原因”，而不是“这就是为什么不能/不应该完成”，所以我只是说“您可以通常使用幺半群，而且函子通常是可应用的。”
我很想说我想选择这样的公理，这样FunctorPlus 对Functor 的添加量与Alternative 对Applicative 的添加量一样多。不管那是什么意思。但我刚刚注意到Alternative 只不过是一个Monoid。所以，也许我应该要求Alternative 的实际使用超过Applicative + Monoid。无论如何，再次考虑我的预期用例让我意识到FunctorPlus 对此没有任何帮助。