为什么 Haskell 中没有 IO 转换器? [英] Why is there no IO transformer in Haskell?

问题描述

每个其他 monad 都带有一个转换器版本，据我所知，转换器的想法是 monad 的通用扩展.按照其他转换器的构建方式，IOT 将类似于

Every other monad comes with a transformer version, and from what I know the idea of a transformer is a generic extension of monads. Following how the other transformers are build, IOT would be something like

newtype IOT m a = IOT { runIOT :: m (IO a) }

我可以在现场制作有用的应用程序:IOT Maybe 可以做一个 IO 动作或什么都不做，IOT [] 可以建立一个列表，以后可以成为 sequenced.

for which I could make up useful applications on the spot: IOT Maybe can either do an IO action or nothing, IOT [] can build a list that can later be sequenced.

那么为什么 Haskell 中没有 IO 转换器?

So why is there no IO transformer in Haskell?

(注意:我看过 这篇关于 Haskell Cafe 的帖子，但不能理解它.另外，ST 变压器的 Hackage 页面 在其描述中提到了一个可能相关的问题，但没有提供任何细节.)

(Notes: I've seen this post on Haskell Cafe, but can't make much sense of it. Also, the Hackage page for the ST transformer mentions a possibly related issue in its description, but doesn't offer any details.)

推荐答案

考虑IOT Maybe的具体例子.您将如何为此编写 Monad 实例?你可以从这样的事情开始:

Consider the specific example of IOT Maybe. How would you write a Monad instance for that? You could start with something like this:

instance Monad (IOT Maybe) where
    return x = IOT (Just (return x))
    IOT Nothing >>= _ = IOT Nothing
    IOT (Just m) >>= k = IOT $ error "what now?"
      where m' = liftM (runIOT . k) m

现在你有 m' :: IO (Maybe (IO b))，但你需要Maybe (IO b)类型的东西，其中——最重要的是--Just 和 Nothing 之间的选择应该由 m' 决定.这将如何实施?

Now you have m' :: IO (Maybe (IO b)), but you need something of type Maybe (IO b), where--most importantly--the choice between Just and Nothing should be determined by m'. How would that be implemented?

答案当然是它不会，因为它不能.你也不能证明一个 unsafePerformIO 在那里，隐藏在一个纯接口后面，因为从根本上说，你要求一个纯值——Maybe 构造函数的选择——依赖IO 中的某些结果.Nnnnnnope，不会发生的.

The answer, of course, is that it wouldn't, because it can't. Nor can you justify an unsafePerformIO in there, hidden behind a pure interface, because fundamentally you're asking for a pure value--the choice of Maybe constructor--to depend on the result of something in IO. Nnnnnope, not gonna happen.

在一般情况下情况更糟，因为任意(通用量化)Monad 比 IO 更不可能解包.

The situation is even worse in the general case, because an arbitrary (universally quantified) Monad is even more impossible to unwrap than IO is.

顺便说一下，您提到的 ST 转换器的实现方式与您建议的 IOT 不同.它使用ST的内部实现作为State-like monad，使用编译器提供的magic pixie powder特殊原语，并定义了一个>StateT 类基于此的转换器.IO 在内部实现为更神奇的 ST，因此可以用类似的方式定义假设的 IOT.

Incidentally, the ST transformer you mention is implemented differently from your suggested IOT. It uses the internal implementation of ST as a State-like monad using magic pixie dust special primitives provided by the compiler, and defines a StateT-like transformer based on that. IO is implemented internally as an even more magical ST, and so a hypothetical IOT could be defined in a similar way.

这并没有真正改变任何东西，除了可能让您更好地控制由 IOT 引起的不纯副作用的相对顺序.

Not that this really changes anything, other than possibly giving you better control over the relative ordering of impure side effects caused by IOT.

这篇关于为什么 Haskell 中没有 IO 转换器?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！