I don’t use ST much, but sometimes it is just the best solution. This can be in many scenarios:
- There are already well-known, efficient ways to solve a problem. Quicksort is a perfect example of this. It is known for its speed and in-place behavior, which cannot be imitated by pure code very well.
- You need rigid time and space bounds. Especially with lazy evaluation (and Haskell doesn’t even specify whether there is lazy evaluation, just that it is non-strict), the behavior of your programs can be very unpredictable. Whether there is a memory leak could depend on whether a certain optimization is enabled. This is very different from imperative code, which has a fixed set of variables (usually) and defined evaluation order.
- You’ve got a deadline. Although the pure style is almost always better practice and cleaner code, if you are used to writing imperatively and need the code soon, starting imperative and moving to functional later is a perfectly reasonable choice.
When I do use ST (and other monads), I try to follow these general guidelines:
- Use Applicative style often. This makes the code easier to read and, if you do switch to an immutable version, much easier to convert. Not only that, but Applicative style is much more compact.
- Don’t just use ST. If you program only in ST, the result will be no better than a huge C program, possibly worse because of the explicit reads and writes. Instead, intersperse pure Haskell code where it applies. I often find myself using things like
STRef s (Map k [v]). The map itself is being mutated, but much of the heavy lifting is done purely. - Don’t remake libraries if you don’t have to. A lot of code written for IO can be cleanly, and fairly mechanically, converted to ST. Replacing all the
IORefs withSTRefs andIOs withSTs in Data.HashTable was much easier than writing a hand-coded hash table implementation would have been, and probably faster too.
One last note – if you are having trouble with the explicit reads and writes, there are ways around it.