Choosing an implementation of a function with a given signature - haskell

Question

I want have some piece of code where I want to call a function foo with different implementations of foo residing in different modules.
Like
foo :: String -> IO[String]
module A:
foo :: String -> IO[String]
foo x = whatever
module B:
foo :: String -> IO[String]
foo x = whatever (different)
and then call the appropriate function based on some parameter. I could do with qualified imports:
import qualified ModuleA as A
import qualified ModuleB as B
bar :: String -> String -> IO[String]
bar moduleToChoose x = case moduleToChoose of
"A" -> A.foo x
"B" -> B.foo x
_ -> Uh oh...
This, however basically screams "There is a so much more elegant™ solution to this but you just don't get it!" Is there a better solution?

Answer 1

Modules aren't first class in Haskell, and so there is no way to use them directly as parameters. In any case, an improvement on your solution would be using a sum type to encode the distinction in a richer and safer way. That can feel pretty natural given meaningful names for modules, types and values (i.e., names that actually reflect what you are trying to do):
import qualified Formatting.Mimsy as Mimsy
import qualified Formatting.Slithy as Slithy
data FormattingStyle = Mimsy | Slithy
foo :: FormattingStyle -> String -> IO [String]
foo style x = case style of
Mimsy -> Mimsy.foo x
Slithy -> Slithy.foo x
You might want to take this a step further and encode the case switch using a type class:
class Fooer a where
foo :: a -> String -> IO [String]
data Mimsy = Mimsy
instance Fooer Mimsy where
foo _ x = undefined -- etc.
data Slithy = Slithy
instance Fooer Slithy where
foo _ x = undefined -- etc.
Another possibility is to use newtype wrappers around String and a Fooable class, akin to Lee Duhem's answer. Either way, using classes for that feels like overkill to me, so I'd stick with the simple sum type solution.
Yet another approach is using records of functions instead of type classes. That, too, is overkill here, though arguably less so than using classes:
data Fooer = Fooer { foo :: String -> IO [String] }
-- Export only mimsy and slithy, and not the Fooer constructor.
mimsy :: Fooer
mimsy = Fooer { foo = Mimsy.foo }
slithy :: Fooer
slithy = Fooer { foo = Slithy.foo }

Answer 2

I would change bar to take the auxiliary funcion directly as a parameter, instead of using a selector parameter.
bar :: (String -> IO [String]) -> String -> IO [String]
Outside the function (possibly in my Main.hs) I would construct the following map:
strategies :: M.Map String (String -> IO [String])
strategies = M.fromList [("A",A.foo), ("B",B.foo)]
This map allows us to decouple the aggregation of the known implementations from the selection of what implementation to use.
The process of looking into the map and constructing the actual bar' :: String -> IO [String] function in which we are interested should be relegated to the outermost layers of your program. That way, dependencies are minimized and "strategy not found" errors are detected sooner.

Answer 3

One possible solution is using user-defined typeclass, like this:
FooClass.hs
module FooClass (FooClass(..)) where
class FooClass a where
bar :: a -> IO [String]
A.hs
module A where
import FooClass
data A = A String deriving (Show)
foo :: A -> IO [String]
foo (A s) = return ["A", s]
instance FooClass A where
bar = foo
B.hs
module B where
import FooClass
data B = B String deriving (Show)
foo :: B -> IO [String]
foo (B s) = return ["B", s]
instance FooClass B where
bar = foo
After all those code, you can use them like this:
t.hs
import FooClass
import A
import B
main = do
a <- bar (A "bar")
b <- bar (B "bar")
putStrLn $ show (a, b)
Testing:
$ runhaskell t.hs
(["A","bar"],["B","bar"])