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?
When is it OK to use 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. :-)
Very informative post. Thank you for taking the time to write this for me. <3 –
Ammonite
Also, don't take the non-upvotes personally. People upvote Dons just because he's dons. :p –
Ammonite
Glad you liked it, thanks for letting me know. It's my first (somewhat) longer piece on Haskell and was quite fun to write. :-) –
Diehard
Just noticed that the way in which I remarked upon ST, even though it was just as short and tangential to the main point as the present version, really needed to be corrected... Which it now is. One musn't be sloppy about tangential remarks! :-) The actual discussion of the State vs IORef issue is entirely unaffected, though, and I still believe it to be correct. –
Diehard
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.
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.
That opened my eyes a bit. For a beginner,
StateT s IO was an obvious, and obviously inferior now, solution. –
Adelaidaadelaide Isn't there a difference between
Stateand ST that in ST the state is modified "in-place"? –
Raychel @Alexey: Yes,
State and ST are different, but both are capable of solving essentially the same problems. –
Kendrakendrah @BartekBanachewicz, there are actually good reasons to use
StateT s IO sometimes. In particular, the compiler is often much better at optimizing it than at optimizing IORef usage. For example, you have a decent chance of getting an Int state unboxed with StateT Int IO, but you'll have to replace the IORef with a PrimArray or similar if you want a real unboxed mutable Int. –
Tagmemic I use STRef when the state is localized and do not require interaction with the environment.
© 2022 - 2024 — McMap. All rights reserved.