haskell - 仅允许将相同的 Monad 类型与 `>>` 运算符连接背后的逻辑是什么？

Question

虽然可以绑定(bind) IO [[Char]] 和 IO () 但不允许绑定(bind) Maybe 和 IO。有人能举例说明这种放松会如何导致糟糕的设计吗？为什么尽管 Monad 本身不允许，但允许 Monad 的多态类型中的自由？

Answer 1

有很多很好的理论理由，包括“那不是 Monad 是什么”。但是，让我们暂时搁置一边，看看实现细节。

首先 - Monad 并不神奇。它只是一个标准类型类。 Monad 的实例只有在有人编写时才会创建。

编写该实例定义了 (>>) 的工作方式。通常它是通过 (>>=) 的默认定义隐式完成的，但这只是证明 (>>=) 是更通用的运算符，并且写作它需要做出与编写 (>>) 相同的决定。

如果您有一个处理更一般类型的不同运算符，您必须回答两个问题。首先，类型是什么？其次，您将如何着手提供实现？从您的问题来看，确实不清楚所需的类型是什么。我猜是以下其中一项:

class Poly1 m n where
    (>>) :: m a -> n b -> m b

class Poly2 m n where
    (>>) :: m a -> n b -> n b

class Poly3 m n o | m n -> o where
    (>>) :: m a -> n b -> o b

所有这些都可以实现。但是在实际使用它们时，您失去了两个非常重要的因素。

1. 您需要为计划一起使用的每一对类型编写一个实例。这是一项比每种类型的实例要复杂得多的任务。关于 n 与 n^2 的一些事情。
2. 你失去了可预测性。该操作甚至做什么？这是理论与实践相交的地方。 Monad 背后的理论对操作有很多限制。这些限制被称为“monad 法则”。它们超出了 Haskell 的验证能力，但任何不遵守它们的 Monad 实例都被认为是错误的。最终结果是，您可以快速地对 Monad 操作做什么和不做什么建立直觉。您可以使用它们而无需查找所涉及的每种类型的详细信息，因为您知道它们所遵循的属性。我建议的那些可能的类(class)都没有给你任何这样的保证。你根本不知道他们在做什么。