为什么 Control.Monad.Morph.hoist 有 Monad 约束？

【问题标题】：Why does Control.Monad.Morph.hoist have a Monad constraint?为什么 Control.Monad.Morph.hoist 有 Monad 约束？
【发布时间】：2016-10-08 03:49:54
【问题描述】：

Control.Monad.Morph 包括

class MFunctor t where
  hoist :: Monad m => (forall a. m a -> n a) -> t m b -> t n b

据我所知，所包含的实例都没有使用Monad m 约束。一个人怎么可能这样做？是否存在使用约束的有效实例（鉴于hoist id = id，我很难想象如何使用）？约束在m 而不是n 有什么意义？

【问题讨论】：

我原以为 Control.Monad.Trans.Compose 会出现一些问题，但在 hoist 上没有 Monad m 时，一切都可以正常编译...
也许是因为它只对 monad 有意义？据我所知，它是一个单子转换器（堆栈）上的函子。
@Alec Control.Monad.Trans.Compose 没有 MFunctor 实例。

标签： haskell monads typeclass functor

【解决方案1】：

Control.Monad.Morph 是 pipes 的衍生产品，所以我猜它的存在是因为 Proxy 的 MFunctor 实例需要它...果然是 used there。

instance MFunctor (Proxy a' a b' b) where
    hoist nat p0 = go (observe p0)
      where
        go p = case p of
            Request a' fa  -> Request a' (\a  -> go (fa  a ))
            Respond b  fb' -> Respond b  (\b' -> go (fb' b'))
            M          m   -> M (nat (m >>= \p' -> return (go p')))
            Pure    r      -> Pure r

但我认为不需要。 m >>= return . f 是 fmap f m。它可能应该是一个 Functor 约束，并且该代码早于 monad-applicative 提案的实施。

【讨论】：

你知道这是在做什么吗？语义需要Monad（或Functor）约束，还是只需要效率？
它在m中递归地映射hoist nat。 Functor 约束对于任何像m (t m a) 这样的形式的转换器t m a 来说都不应该是一个令人惊讶的要求。