haskell - 为什么 Kleisli 不是 Monoid 的一个实例？

Question

如果您希望附加两个 (a -> m b) 类型的函数，以便只获得一个附加两个结果的相同类型的函数，则可以使用 Kleisli 来执行此操作:

instance (Monad m, Monoid b) => Monoid (Kleisli m a b) where
    mempty = Kleisli (\_ -> return mempty)
    mappend k1 k2 =
        Kleisli g
            where
                g x = do
                    r1 <- runKleisli k1 x
                    r2 <- runKleisli k2 x
                    return (r1 <> r2)

但是，目前 Control.Arrow 中没有定义这样的实例。 .
通常，在 Haskell 中，我怀疑有一个很好的理由，但找不到哪一个。
笔记
这个问题与 this one 非常相似。 .但是，对于 Monoid，我看不到定义实例的方法，例如:

instance (Monad m, Monoid b) => Monoid (a -> m b) where
    [...]

因为已经有一个实例:

instance Monoid b => Monoid (a -> b) where
    [...]

Answer 1

在图书馆设计业务中，我们在这里面临一个选择点，我们选择在我们的集体政策中不完全一致(或缺乏一致)。
Monoid Monad 的实例(或 Applicative )类型构造函数可以以多种方式出现。逐点提升总是可用的，但我们没有定义

instance (Applicative f, Monoid x) => Monoid (f x) {- not really -} where
  mempty         = pure mempty
  mappend fa fb  = mappend <$> fa <*> fb

请注意 instance Monoid (a -> b)就是这样的逐点提升，所以 (a -> m b) 的逐点提升每当 m b 的 monoid 实例时都会发生对 b 上的幺半群进行逐点提升.

我们一般不做逐点提升，不仅因为它会阻止其他 Monoid其载体恰好是应用类型的实例，还因为 f 的结构通常被认为比 x 更重要.一个关键的例子是自由幺半群，更广为人知的是 [x]。 ，这是一个 Monoid通过 []和 (++) ，而不是逐点提升。 monoidal 结构来自列表包装，而不是来自包装的元素。

我首选的经验法则确实是将类型构造函数中固有的幺半群结构优先于逐点提升或类型的特定实例化的幺半群结构，例如 a -> a 的组合幺半群。 .这些可以而且确实得到 newtype包装。

关于是否 Monoid (m x) 的争论爆发了。应该与 MonadPlus m 重合只要两者都存在(与 Alternative 类似)。我的感觉是唯一的好 MonadPlus实例是 Monoid 的副本例如，但其他人不同。尽管如此，图书馆在这件事上并不一致，尤其是在(很多读者会看到我的这个老熊来了)…

... Maybe 的幺半群实例, 这忽略了我们经常使用 Maybe 的事实对可能的故障进行建模，而是观察到，如果半群还没有一个中性元素，则可以使用相同的数据类型想法来添加一个额外的元素。这两种结构产生了同构类型，但它们在概念上不是同源的。 ( 编辑 更糟糕的是，这个想法实现起来很笨拙，给实例一个 Monoid 约束，而只需要 Semigroup。我想看看 Semigroup -extends-to - Monoid 想法已实现，但不适用于 Maybe。)

回到 Kleisli特别是，我们有三个明显的候选实例:

Monoid (Kleisli m a a)与 return和 Kleisli 组成

MonadPlus m => Monoid (Kleisli m a b)起重 mzero和 mplus逐点超过 ->

Monoid b => Monoid (Kleisli m a b)提升 b 的幺半群结构超过 m然后 ->

我预计没有做出任何选择，只是因为尚不清楚该做出哪个选择。我不敢这么说，但我的投票是 2，优先考虑来自 Kleisli m a 的结构来自 b的结构.