When is it OK to use an IORef?

Question

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?

Answer 1

I use STRef when the state is localized and do not require interaction with the environment.

Answer 2

Hmm. You'd use an IORef when you need some mutable state but are in a single threaded environment. Or when you want a mutable field inside a larger structure that is in turn held by a synchronization variable.

In general, use MVars. They have more robust semantics.

Answer 3

Personally, I'd say it's fine to use IORefs when and only when you're already using IO. Otherwise, always State, unless you need the superior performance of ST. It's possible to use multiple threads of state with the State monad, with a few helper functions – you just make the state a tuple or record, and define functions to set, get, or update each field separately.

In particular, there's not usually much point in using StateT s IO. If you're already in IO, you already have mutable state, so you might as well use it – ReaderT (IORef s) IO for example.

Answer 4

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. :-)