IORef in Haskell

Question

I was wondering if there was a legitimate usage for IORef in Haskell? More specifically I would be thankful if someone could address the following or point to an appropriate place to know more about this:

1. Is using IORef considered a bad Haskell practice? If yes, why? More specifically how is it better or worse than an IO monad?

2. If one was looking to add state to a program, isn't state monad a better (purer) way to do it. If one was feeling more imperative couldn't he still use STM, and MVar, and still be better off?

3. Are there programming scenarios that are easily handled using IORefs rather than STM, MVar, or the pure IO?

I am reading a paper that uses IORef for the code snippets, and it has been difficult read for me owing to the negative perception I have towards IORef. Rather than wallow in my ignorance, I thought asking my fellow Haskellers for help might be a better idea.

Spinifex

Related, though I wouldn't call it a dup. – Rees

I've probably only used IORef in situations involving concurrency. Yes, it would be bad to use an IORef just so you could write code in an imperative style. MVar and the STM vars are great, but if IORef does what you need there's nothing wrong with using it. – Bickering

I'm guessing that paper is on concurrency? I've not really seen IORef outside of concurrency applications, as pointed out above. – Chilson

@AJFarmar The paper is about using type theory in the field of software security. – Spinifex

Answer 1

First off, I think that for code snippets in a paper, using IORef is perfectly sensible, particularly if the paper isn't about best practices for mutable references or concurrency. IORef is simple to understand, has straightfoward syntax and semantics (especially in a non-concurrent setting), and is a natural choice if you want the reader to concentrate on aspects of your examples other than the IORefs. It's unfortunate that the author's approach has backfired for you -- just ignore the IORefs and pay attention to what the rest of what the paper is saying.

(If the paper was about best practices for mutable references or concurrency, perhaps it was written before better alternatives were available.)

Anyway, to your larger question, the main objections to using IORef would be:

• Like any other mechanism for introducing mutable state into your program, it makes your code more difficult to reason about, maintain, test, etc. -- all the usual things that functional programming proponents would say give FP an "edge" over mutation-intensive imperative algorithms.
• It's just a newtype wrapper around a specialized STRef RealWorld, and the only thing it adds over STRef are some atomic operations. In non-concurrent code, there's no good reason not to use STRef s values in an ST s monad, since they're more flexible -- you can run them in pure code with runST or, if needed, in the IO monad with stToIO.
• In concurrent code, there are more powerful abstractions, like MVar and STM that are much easier to work with than IORefs.

So, to the extent that mutable state is "bad" and -- if you really need it -- better alternatives are available depending on whether you do or don't need concurrency, there's not much to recommend IORef.

On the other hand, if you are already working on some non-concurrent code in the IO monad because you need to perform actual IO operations, and you genuinely need some pervasive mutable state that isn't easy to disentangle from the IO, then using IORefs seems legitimate.

With respect to your more specific questions:

1. I guess it would be safe to say that using IORef is considered "bad practice" when a weaker tool would do the job. That weaker tool might be an STRef s, or better yet a State monad or better yet a rewritten higher-order algorithm that doesn't need any state at all. Because IORef combines IO with mutable references, it's kind of an imperative sledgehammer that's likely to lead to the most unidiomatic Haskell code possible, so it's best avoided unless it's "obviously" the right solution for a particular problem.

2. The State monad is usually the preferred idiomatic way to add state to a program, but it provides the "illusion" of a mutable state by threading a sequence of immutable state values through the computation, and not all algorithms can be efficiently implemented this way. Where true mutable state is required, an STRef is usually the natural choice in a non-concurrent setting. Note that you probably wouldn't use MVar or STM in a non-concurrent setting -- there's no reason to use them in this case, and they would force you into the IO monad even if you didn't otherwise need it.

3. Yes, there are programming scenarios where either IORef or STRef are preferable to State, STM, MVar, or pure IO (see below). There are few scenarios where IORef is obviously preferable to STRef, but -- as mentioned above -- if you're already in the IO monad and have a need for true mutable state that's entangled with IO operations, then IORef probably has the edge over STRef in terms of slightly cleaner syntax.

Some examples of cases where either IORef or STRef is a good approach:

• Data.Unique in the base package uses an IORef as a global counter for generating unique objects.
• In the base library, the file handle internals make extensive use of IORefs for attaching buffers to handles. This is a good example of "already being in the IO monad with entangled IO operations".
• Many vector algorithms are most efficiently implemented using mutable vectors (e.g., even something as simple as counting byte frequencies in a block of data). If you use mutable vectors from the vector package, then technically you're using mutable byte arrays rather than STRef or IORef, but it's still morally equivalent.
• The equivalence package uses STRefs for an efficient implementation of the union-join algorithm.
• As a somewhat on-the-nose example, if you're implementing an interpreter for an imperative language, then using IORef or STRef values for the mutable variables is generally going to be most efficient.

Sesterce