在类型类定义中添加额外的函数/组合器有什么优点和缺点？答案

【问题标题】：What are the pros and cons of adding additional functions/combinators to a typeclass definition?在类型类定义中添加额外的函数/组合器有什么优点和缺点？
【发布时间】：2012-09-20 15:14:52
【问题描述】：

看着source for Monad：

class  Monad m  where
    (>>=)       :: forall a b. m a -> (a -> m b) -> m b
    (>>)        :: forall a b. m a -> m b -> m b

    return      :: a -> m a
    fail        :: String -> m a

    {-# INLINE (>>) #-}
    m >> k      = m >>= \_ -> k   -- <-- !! right here !!
    fail s      = error s

您可以看到>> 有一个默认实现。我的问题是，它被认为是好的还是坏的做法，为什么要在类型类中包含一个函数/组合器 in，而不是在类型类之外单独提供它？

也就是说，为什么不呢：

class  Monad m  where
    (>>=)       :: forall a b. m a -> (a -> m b) -> m b

    return      :: a -> m a
    fail        :: String -> m a

    fail s      = error s

还有其他地方：

(>>)        :: forall a b. m a -> m b -> m b
{-# INLINE (>>) #-}
m >> k      = m >>= \_ -> k

【问题讨论】：

标签： haskell typeclass

【解决方案1】：

据我所知，包含“额外”功能的主要原因有两个：

效率：有时存在效率低下的泛型实现，而该类的作者期望特定于实例的实现要好得多。在这种情况下，在类中包含具有默认实现的函数意味着实例可以根据需要使用优化版本，但不是必需的。有关这方面的有趣示例，请查看 Foldable。 Monad 也是如此。
实现的选择：通常有几个类函数的子集可以使用；包括所有潜在功能并相互使用默认实现意味着实例可以选择一些功能来实现并自动获取其余功能。这也适用于Foldable，但Eq 是一个更简单的例子。

【讨论】：

能否也列出缺点？
@TikhonJelvis：说实话，我不太确定有哪些客观缺点。可以说它有点混淆了类的性质，并且可能使 GHC 内部使用的类字典膨胀，但如果有任何明显的、完全的缺点，我不知道。
我也是这么想的。但这很奇怪，因为据我所知，这些默认实现很少使用。
@C.A.McCann 我想说在一个类中包含更多方法的缺点是它可能会减少可能实现的数量；例如Monoid 是一个不错的类型类，Semigroup 也是。（当然，这不适用于 combinators - 仅适用于在概念上与任何其他方法具有不同需求的方法。）
@DanielWagner：当然，但这里只有这样的组合器有问题，如果没有问题的上下文，我的回答肯定不清楚......

【解决方案2】：

这样，自定义 >> 可以为 monad 实现，它可以比通过 m >>= \_ -> k 更有效或更自然地完成，但仍然存在默认实现。

【讨论】：

【解决方案3】：

在类型类中包含方法的另一个论点是它们何时应该满足某些定律，或者它们何时使这些定律的陈述更清晰。我认为法律应该在道德上与类型类相关联（“我必须提供什么才能声明这个类的实例？”）例如，您可能更喜欢用return 来陈述单子定律， join 和 fmap，而不是 return 和 >>=；这鼓励您将所有四个运算符都放在类型类中（并使Monad 成为Functor 的子类！），并根据join 给出>>= 的默认定义，反之亦然。`

【讨论】：