Excerpts from Oliver Charles's message of Mon Feb 21 08:53:48 -0500 2011:

Yes, this is a concern to me as well. The only places I've used unsafePerformIO is with Query objects, which I am mostly treating as immutable data, and never exposing anyway to modify query objects.

That is a good way to start thinking about it. If there is an efficient mechanism for copying query objects, you can also implement "persistent update" (e.g. copy the structure and then mutate it).

However, what is better? Should I avoid taking this risk/assumption of immutability and use this within the IO monad also? I guess my biggest fear is that this entire library is only usable in the IO monad, which from what I understand limits my ability to test easily.

Don't take the risk: verify for yourself that there is no risk! Note that putting things in IO doesn't get you off the concurrency hook: things in IO can be run in different threads and you need to synchronize them. Indeed, as the Xapian faq states: If you want to use the same object concurrently from different threads, it's up to you to police access (with a mutex or in some other way) to ensure only one method is being executed at once. It is admittedly more annoying to test things in IO. One thing you can do is if database objects are completely isolated from one another (which seems to be the case) you can build up a custom monad for manipulating this object in a single-threaded and/or thread safe manner. I did something like this (actually, I needed to enforce more complex invariants about when what functions could get called), but unfortunately it was for work and the code hasn't been cleared for publication yet. Cheers, Edward