haskell - 什么时候可以使用 IORef？

Question

一直让我困惑的一件事是现在是否适合使用 IORef。在决定是否对任务使用 IORef 时，是否应遵循任何准则？什么时候是使用 State monad 而不是 IORef 的好时机？

Answer 1

状态及其相关的 ST 都产生可以作为单元运行的“整体”状态计算。他们基本上将可变状态视为产生结果所需的中间数据，但其本身不应引起程序的其余部分的兴趣。

另一方面，放入 IORef 中的内容并不是要运行的“计算”——它只是一个保存简单值的盒子，可以以相当任意的方式在 IO 中使用该值。这个盒子可以放在数据结构中，在程序(的 IO 部分)中传递，在方便的时候替换其内容，由函数关闭等。事实上，变量和变量的很多困惑性质像 C 这样的语言的指针可以使用 IORefs 进行建模，这为任何希望维护自己能够用任何语言编写 C 代码的声誉的专家 C 程序员提供了很大的帮助......这绝对是需要小心使用的东西。

尽管如此，有时在单个代码块中隔离与一段可变状态的所有交互即使不是完全不可能，也是极其笨拙的——某些状态片段必须被传递在这种情况下，盒子方法可能是唯一的选择。 chapter introducing mutable state在 48 小时内为自己编写一个方案教程(顺便说一下，强烈推荐)提供了一个示例。 (请参阅链接，详细讨论为什么使用 IORef(而不是 State 或 ST)在某种 Scheme 解释器设计中对 Scheme 环境进行建模是最合适的。)

简而言之，这些环境需要以任意方式嵌套，并在用户交互实例之间进行维护(在Scheme REPL 中输入的(define x 1) 可能会导致用户稍后能够输入 x 并返回 1 作为值)，将对象模型放入Scheme函数中(因为Scheme函数接近它们创建的环境)等。

总而言之，我想说，如果一项任务看起来非常适合它，那么 State 政府将倾向于提供最干净的解决方案。如果需要多个独立的状态部分，也许 ST 可以提供帮助。然而，如果有状态计算难以处理或不可能锁定在自己的代码段中，状态需要在复杂程序的大部分生命周期中以可修改的形式持续存在等，那么 IORef 可能只是适当的事情。

话又说回来，如果需要一种可以通过 IO 代码以受控方式传递和交互的可变状态，为什么不看看 STM 及其 TVar!它们在并发情况下要好得多，事实上，使得解决一些与并发相关的任务实际上很简单。不过，这与问题并不真正相关，所以我会拒绝详细说明。 :-)