在 Haskell 中，我觉得非常漂亮的一件事是它使用 Monads 作为有效 Action 的抽象。它创建了一种非常优雅的方式来表达命令式代码，同时还允许在保证正确性的情况下发生强大的事情。
IO monad 似乎并不特定于强类型语言。具体来说，在我看来，用动态类型语言实现 IO monad 并不困难或革命性的。然后只需要限制语言，使所有 IO Action 都简单地在 IO monad 中产生 Action 。
话虽如此，我还没有看到任何动态类型的语言(也许我只是不够努力)，但使用 monad 隔离副作用。有什么理由会这样吗？ (或者它们存在吗？)
最佳答案
您在这里混淆了两个问题。这不能怪你，因为很多关于 Haskell 的文献也将这两个想法混为一谈。但类型化 IO 是 Haskell 方法的魔力所在。 IO 类型形成 monad 的事实并不那么重要。这只是意味着它可以与其他类型共享库函数，而不是自己重新实现它们。
monad 抽象在动态类型语言中并不能很好地工作。当然，它们可以为您提供 fmap 的类似物。和 (>>=) ，但是对于return没有好办法以动态类型语言工作。它在仅出现在其返回类型中的类型变量中是多态的。我不知道有任何具有动态输入功能的语言可以理智地处理这种情况。我想可能有一些方法可以使用免费的 monad 构造和大量的内省(introspection)来破解它，但我怀疑它似乎永远不会是一个有用的抽象。
另一部分，类型化 IO，可能会集成到动态语言中。显然它将成为运行时标记的 IO，而不是类型化的 IO。但是必须构建有关该语言的所有内容以支持它。程序执行的入口点必须指定为一个 IO 值，而不是像大多数动态语言选择的那样只执行文件中的每一行的常见习惯用法。然后你必须使用组合器或语法来组合 IO 值，就像在 Haskell 中一样。最后，您必须忍受用户声称该语言太难使用，因为它与他们习惯的不同。
真的，这是最后一个杀手。
关于haskell - 动态类型语言中的 IO Monad，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/24666384/