I'm writing a MUD server in Haskell (MUD = Multi User Dungeon: basically, a multi-user text adventure/role-playing game). The game world data/state is represented in about 15 different IntMap
s. My monad transformer stack looks like this: ReaderT MudData IO
, where the MudData
type is a record type containing the IntMap
s, each in its own TVar
(I'm using STM for concurrency):
data MudData = MudData { _armorTblTVar :: TVar (IntMap Armor)
, _clothingTblTVar :: TVar (IntMap Clothing)
, _coinsTblTVar :: TVar (IntMap Coins)
...and so on. (I'm using lenses, thus the underscores.)
Some functions need certain IntMap
s, while other functions need others. Thus, having each IntMap
in its own TVar
provides granularity.
However, a pattern has emerged in my code. In the functions that handle player commands, I need to read (and sometimes later write) to my TVar
s within the STM monad. Thus these functions end up having an STM helper defined in their where
blocks. These STM helpers often have quite a few readTVar
operations in them, as most commands need to access a handful of the IntMap
s. Furthermore, a function for a given command may call out to a number of pure helper functions that also need some or all of the IntMap
s. These pure helper functions thus sometimes end up taking a lot of arguments (sometimes over 10).
So, my code has become "littered" with lots of readTVar
expressions and functions that take a large number of arguments. Here are my questions: is this a code smell? Am I missing some abstraction that would make my code more elegant? Is there a more ideal way to structure my data/code?
Thanks!
Yes, this obviously makes your code complex and clutters the important code with a lot of boilerplate details. And functions with more than 4 arguments are a sign of problems.
I'd ask the question: Do you really gain anything by having separate
TVar
s? Isn't it a case of premature optimization? Before taking such a design decision as splitting your data structure among multiple separateTVar
s, I'd definitely do some measurements (see criterion). You can create a sample test that models the expected number of concurrent threads and frequency of data updates and check what are you really gaining or losing by having multipleTVar
s vs a single one vs anIORef
.Keep in mind:
STM
transaction, the transactions can get restarted several times before they manage to successfully complete. So under some circumstances, having multiple locks can actually make things worse.IORef
instead. It's atomic operations are very fast, which could compensate for having a single central lock.STM
or aIORef
transaction for a long time. The reason is laziness: You only need to create thunks within such a transaction, not to evaluate them. This is true in particular for a single atomicIORef
. The thunks are evaluated outside such transactions (by a thread that inspects them, or you can decide to force them at some point, if you need more control; this can be desired in your case, as if your system evolves without anybody observing it, you can easily accumulate unevaluated thunks).If it turns out that having multiple
TVar
s is indeed crucial, then I'd probably write all the code in a custom monad (as described by @Cirdec while I was writing my answer), whose implementation would be hidden from the main code, and which would provide functions for reading (and perhaps also writing) parts of the state. It'd then be run as a singleSTM
transaction, reading and writing only what's needed, and you could have a pure version of the monad for testing.