什么时候可以使用IOREF?

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

另一方面,放在IOREF中的不是要运行的“计算”——它只是一个包含简单值的框,可以在IO中以相当任意的方式使用。这个框可以放在数据结构中,绕过程序的(IO部分),在任何方便的时候替换其内容,用函数等关闭。事实上,许多像C这样的语言的变量和指针的混乱性质可以用iorefs建模,为任何专家C程序提供很大的帮助。阿默尔希望维护他/她的声誉,能够用任何语言编写C代码…这绝对是要小心使用的东西。

不过,有时也是这样 极其 如果不是完全不可能的话,那么在一个代码块中隔离与一个可变状态块的所有交互——一些状态块必须简单地传递,放在数据结构中等等。在这种情况下,Box方法可能是唯一的选择。这个 chapter introducing mutable state 其中48小时自编一个方案教程(顺便说一下,强烈推荐)提供了一个例子。(请参阅链接,了解为什么在方案解释器的特定设计中使用IOREF(而不是State或ST)对方案环境进行建模是最合适的。)

简而言之,这些环境需要以任意方式嵌套,在用户交互实例之间维护(a (define x 1) 在方案repl上键入可能会导致用户稍后能够键入 x 然后返回1作为值),放入对象建模方案函数(因为方案函数靠近创建它们的环境)等。

总的来说,我会说,如果一个任务看起来非常适合它,那么州政府将倾向于提供最干净的解决方案。如果需要多个独立的状态块,那么ST可能会有所帮助。但是,如果状态计算不容易或者不可能锁定在自己的代码中,那么状态需要在复杂程序的大部分生命周期中保持可修改的形式等,那么IOREF可能是合适的。

同样,如果你需要一种可变的状态,这种状态可以通过IO代码来传递和交互,为什么不签出stm和它的tvar呢?在并发性的存在下,它们更加优秀,事实上,它们使解决 一些 并发相关的任务实际上很简单。不过,这与这个问题并没有真正的关系,所以我不想急于详细说明。-)

嗯,当您需要一些可变状态,但处于单线程环境中时,可以使用IOREF。或者当您希望在一个更大的结构中有一个可变字段,而该结构又被同步变量持有时。

通常,使用MVAR。它们有更强大的语义。

就我个人而言,我认为可以使用 IORef 当 只有当 您已经在使用 IO .否则,总是 State 除非你需要 ST .可以使用多个状态线程 状态 monad,使用一些辅助函数,只需将状态设置为元组或记录,并定义要分别设置、获取或更新每个字段的函数。

特别是,通常没有太多的使用点 StateT s IO . 如果你已经在 IO ,您已经具有可变状态,因此您可以使用它。 ReaderT (IORef s) IO 例如。

我使用 STRef 当状态是本地化的并且不需要与环境交互时。