什么时候可以使用IORef? [英] When is it OK to use an IORef?
问题描述
让我一直困惑的一件事是使用IORef是否合适.在决定是否为任务使用IORef时，应遵循哪些准则?什么时候可以在IORef上使用State monad?
状态及其相对的ST都生成整体式"有状态计算，可以作为单元运行.他们基本上将可变状态视为中间数据，这是产生结果所必需的，但其本身并不会引起程序其余部分的兴趣.
另一方面，放在IORef中的内容不是要运行的计算"，它只是一个包含简单值的盒子，可以在IO中以相当任意的方式使用它.此框可以放在数据结构内部，在程序的(IO部分)传递，在方便时可以替换其内容，可以用函数关闭等.事实上，变量和诸如C之类的语言的指针可以使用IORefs进行建模，从而为希望维护自己的能力(无论使用哪种语言编写C代码)的任何专业C程序员提供了极大的帮助. /p>
尽管如此，有时将极其笨拙地(即使不是完全不可能)将所有具有可变状态的交互隔离在单个代码块中-只需简单地传递某些状态即可在周围放置数据结构等.在这种情况下，盒式方法可能是唯一的选择. 本章介绍了在48小时内自行编写方案"的可变状态(强烈建议，顺便说一句)提供了一个示例. (请参阅该链接，很好地讨论了为什么在特定的Scheme解释器设计中使用IORef(而不是State或ST)来对Scheme环境进行建模是最合适的.)
简而言之，这些环境需要以任意方式嵌套，并在用户交互实例之间进行维护(在Scheme REPL上键入的(define x 1)应该应该导致用户以后可以键入x并返回) 1作为值)，放到建模Scheme函数的对象内部(因为Scheme函数在创建它们的环境中封闭)等.
总而言之，我想说的是，如果一项任务看起来完全适合它，国家将倾向于提供最干净的解决方案.如果需要多个单独的状态，也许ST可以提供帮助.但是，如果有状态计算笨拙或无法锁定在自己的代码中，则状态需要在复杂程序的大部分生命周期中以可修改的形式保存，等等，那么IORefs可能就是合适的东西.
然后再说一次，如果需要一种可变状态，可以通过IO代码以受控的方式传递并与之交互，那么为什么不检查STM及其TVar呢！在存在并发的情况下，它们要好得多，以至于实际上使解决与并发相关的 some 任务变得如此简单.但是，这与问题并没有真正的关系，因此我拒绝敦促进行详细说明. :-)
One thing that has always confused me is whether or not it's an okay time to use an IORef. Are there any guidelines that should be followed when deciding whether or not to use an IORef for a task? When is a good time to use the State monad over an IORef?
State and its relative ST both produce `monolithic' stateful computations which may be run as units. They basically treat the mutable state as intermediate data, which is needed to produce a result, but should not, in and of itself, be of interest to the rest of the programme.
On the other hand, what one puts inside an IORef is not a `computation' to be run -- it is just a box holding a simple value which may be used within IO in fairly arbitrary ways. This box may be put inside data structures, passed around the (IO portion of) the programme, have its contents replaced whenever its convenient, be closed over by a function etc. In fact, quite a lot of the messy nature of the variables and pointers of languages like C could be modelled with IORefs, providing great assistance to any expert C programmer wishing to uphold his / her reputation of being able to write C code in whatever language... This is something definitely to be used with care.
Still, it is at times extremely unwieldy, if not downright impossible, to isolate all interactions with a piece of mutable state in a single block of code -- some pieces of state simply must be passed around, put inside data structures etc. In such cases the box approach may be the only option. The chapter introducing mutable state of the Write Yourself a Scheme in 48 Hours tutorial (highly recommended, by the way) provides an example. (See the link for a nice discussion of why it is really most appropriate to use IORefs, as opposed to State or ST, to model Scheme environments in a certain design of a Scheme interpreter.)
In short, those environments need to be nested in arbitrary ways, maintained between instances of user interaction (a (define x 1) typed at the Scheme REPL should presumably result in the user being able later to type in x and get back 1 as the value), put inside objects modelling Scheme functions (since Scheme functions close over the environments they are created in) etc.
To summarise, I'd say that if a task seems at all well suited for it, State will tend to provide the cleanest solution. If multiple separate pieces of state are needed, perhaps ST can help. If, however, the stateful computation is unwieldy or impossible to lock up in its own piece of code, the state needs to persist in a modifiable form for a large part of the life of a complex programme etc., then IORefs may be just the appropriate thing.
Then again, if one needs the sort of mutable state which may be passed around and interacted with in controlled ways by IO code, why not check out STM and its TVars! They are much nicer in the presence of concurrency, so much so, in fact, as to make solving some concurrency-related tasks actually simple. This isn't really related to the question, though, so I'll resist to urge to elaborate. :-)
这篇关于什么时候可以使用IORef?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
