Request-response processor in Haskell

Probably the most elegant way of solving this problem is servant. If servant applies to your situation, you should just use it. If not, the core idea in servant is easy to copy. Frankly, the route you started down is roughly in this direction, and it would eventually lead to this place if taken aggressively enough. There are a couple of issues with it currently.

The first issue is it's more important to capture deserializeAnyRequest in a type class than to capture serializeResponse in a type class. If I have a function A -> B, it's much easier for me to make that into A -> String, discarding type information, given that I know exactly what B is, than to turn it into String -> B which requires recovering type information. The trick is instead of looking at the data to find out what to do, we decide what to do (based on type) and then look at the data to verify that it's what we expect. This is how read, and, less trivially, printf and servant work. So make a type class for deserialization similar to Read.

The next issue is modularity. As you noticed, if we're going to drive our code by type, at some point we're going to need a type to describe all our input. We don't want to declare some giant type for this, at least not all at once. The solution is straightforward and simple: we make a type combinator to combine two types, and then we merely need to combine deserializers somehow and dispatch on the combined result. At a basic level, Either works perfectly fine for this.

Below is a very minimalistic code example illustrating the ideas above. I didn't include an equivalent to serializeResponse, as it's not necessary, but there's nothing wrong with keeping it. The deserializers are just String -> Maybe a functions. This is simple but inefficient. You could readily provide more information at the type level or return a less opaque type that would allow deserializers to be combined efficiently. See servant, for example. The only thing that needs to change to add a new request type (beyond writing the new code) is AppType, and that type can be a combination of type synonyms for subsets of the interface. Note that this approach doesn't preclude you from using a less typed (and more flexible) approach that, e.g., allows adding to request handlers at run-time. You just have a GenericRequest type.

You may also want to look at the finally, tagless approach for a more structured way of handling the request types.

module Main where

class Deserialize a where
    deserialize :: String -> Maybe a

class DoSomething a where
    doSomething :: a -> IO ()

data RequestA = RequestA Int deriving (Read)
instance Deserialize RequestA where
    deserialize s = case reads s of [(a,_)] -> Just a; _ -> Nothing
instance DoSomething RequestA where
    doSomething (RequestA i) = print i

data RequestB = RequestB Bool Bool deriving (Read)
instance Deserialize RequestB where
    deserialize s = case reads s of [(a,_)] -> Just a; _ -> Nothing
instance DoSomething RequestB where
    doSomething (RequestB a b) = print (a && b)

instance (Deserialize a, Deserialize b) => Deserialize (Either a b) where
    deserialize s = case deserialize s of
                        Just a -> Just (Left a)
                        Nothing -> case deserialize s of
                                        Just b -> Just (Right b)
                                        Nothing -> Nothing

instance (DoSomething a, DoSomething b) => DoSomething (Either a b) where
    doSomething (Left a) = doSomething a
    doSomething (Right b) = doSomething b

type AppType = Either RequestA RequestB

main = do
    i <- getLine
    case deserialize i :: Maybe AppType of
        Just a -> doSomething a
        Nothing -> putStrLn "Bad Input"

I should emphasize that this is really minimalistic. More realistically you'll probably want more context provided, most likely via a monad. For example, if you did want to do that GenericRequest thing, you'd probably want to have the deserializer initialized from a map of request handlers, but there is no way to provide that to the deserialize function. deserialize returning its result in a monad or taking an extra "context" parameter (which is a special case of the former) would enable that.

How about having, for each request/response pair, a function like:

type SerializedRequest = String

type SerializedResponse = String

parseSerializedRequest :: SerializedRequest -> Maybe (IO SerializedResponse)

The actual request/response types hide behind the function. We would have a list of these functions, assembled from each of your modules.

Whenever a serialized request arrives, we try each function in sequence until we find a match. The match returns the IO action to perform, along with the serialized response. If more than one action were possible, we can return them in a record.