haskell - Combining multiple states in StateT

Question

I am writing a program that runs as a daemon. To create the daemon, the user supplies a set of implementations for each of the required classes (one of them is a database) All of these classes have functions have type signatures of the form StateT s IO a, but s is different for each class.

Suppose each of the classes follows this pattern:

import Control.Monad (liftM)
import Control.Monad.State (StateT(..), get)

class Hammer h where
  driveNail :: StateT h IO ()

data ClawHammer = MkClawHammer Int -- the real implementation is more complex

instance Hammer ClawHammer where
  driveNail = return () -- the real implementation is more complex

-- Plus additional classes for wrenches, screwdrivers, etc.

Now I can define a record that represents the implementation chosen by the user for each "slot".

data MultiTool h = MultiTool {
    hammer :: h
    -- Plus additional fields for wrenches, screwdrivers, etc.
  }

And the daemon does most of its work in the StateT (MultiTool h ...) IO () monad.

Now, since the multitool contains a hammer, I can use it in any situation where a hammer is needed. In other words, the MultiTool type can implement any of the classes it contains, if I write code like this:

stateMap :: Monad m => (s -> t) -> (t -> s) -> StateT s m a -> StateT t m a
stateMap f g (StateT h) = StateT $ liftM (fmap f) . h . g

withHammer :: StateT h IO () -> StateT (MultiTool h) IO ()
withHammer runProgram = do
  t <- get
  stateMap (h -> t {hammer=h}) hammer runProgram

instance Hammer h => Hammer (MultiTool h) where
  driveNail = withHammer driveNail

But the implementations of withHammer, withWrench, withScrewdriver, etc. are basically identical. It would be nice to be able to write something like this...

--withMember accessor runProgram = do
--  u <- get
--  stateMap (h -> u {accessor=h}) accessor runProgram

-- instance Hammer h => Hammer (MultiTool h) where
--   driveNail = withMember hammer driveNail

But of course that won't compile.

I suspect my solution is too object-oriented. Is there a better way? Monad transformers, maybe? Thank you in advance for any suggestions.

Answer 1

If you want to go with a large global state like in your case, then what you want to use is lenses, as suggested by Ben. I too recommend Edward Kmett's lens library. However, there is another, perhaps nicer way.

Servers have the property that the program runs continuously and performs the same operation over a state space. The trouble starts when you want to modularize your server, in which case you want more than just some global state. You want modules to have their own state.

Let's think of a module as something that transforms a Request to a Response:

Module :: (Request -> m Response) -> Module m

Now if it has some state, then this state becomes noticable in that the module might give a different answer the next time. There are a number of ways to do this, for example the following:

Module :: s -> ((Request, s) -> m (Response s)) -> Module m

But a much nicer and equivalent way to express this is the following constructor (we will build a type around it soon):

Module :: (Request -> m (Response, Module m)) -> Module m

This module maps a request to a response, but along the way also returns a new version of itself. Let's go further and make requests and responses polymorphic:

Module :: (a -> m (b, Module m a b)) -> Module m a b

Now if the output type of a module matches another module's input type, then you can compose them like regular functions. This composition is associative and has a polymorphic identity. This sounds a lot like a category, and in fact it is! It is a category, an applicative functor and an arrow.

newtype Module m a b =
    Module (a -> m (b, Module m a b))

instance (Monad m) => Applicative (Module m a)
instance (Monad m) => Arrow (Module m)
instance (Monad m) => Category (Module m)
instance (Monad m) => Functor (Module m a)

We can now compose two modules that have their own individual local state without even knowing about it! But that's not sufficient. We want more. How about modules that can be switched among? Let's extend our little module system such that modules can actually choose not to give an answer:

newtype Module m a b =
    Module (a -> m (Maybe b, Module m a b))

This allows another form of composition that is orthogonal to (.): Now our type is also a family of Alternative functors:

instance (Monad m) => Alternative (Module m a)

Now a module can choose whether to respond to a request, and if not, the next module will be tried. Simple. You have just reinvented the wire category. =)

Of course you don't need to reinvent this. The Netwire library implements this design pattern and comes with a large library of predefined "modules" (called wires). See the Control.Wire module for a tutorial.